-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Champions meeting minutes of August 15, 2007 9am - 11am PST 1. A Dave Rich 2. A Neil Korpusik 3. A Surrendra Dudani 4. A Brad Pierce 5. A Shalom Bresticker 6. A Francoise Martinolle 7. A Stu Sutherland 8. A Karen Pieper 1. Review IEEE patent policy http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Dave - assume that the patent policy was read Second: Brad 2. Mantis items From sv-ec 1789 Clarification of string behavior Passed unanimously by email vote June 22, 2007 [Feedback from Shalom] Minor comments on 1789, Clarification of string behavior: "1. Change this sentence (on page 128)": in Draft 3a, this is page 126. In 2, " bit [10:0] a = "\x41"; // assigns to a `b000_0100_0001": the back-tic in the comment preceding 'b' should be an apostrophe. In 4, "one of them can be a string literal which is implicitly converted to a string type data object for the comparison": this appears twice, there should be a comma before the word 'which'. Move: Stu - approve the proposal for mantis 1789, with the friendly amendments from Shalom. Second: Shalom Passed unanimously 1787 LRM needs to discuss transition bins of length 1 Approved on April 30, 2007 unanimously. [Feedback from Shalom] 1787 should also refer to 18.5.1 instead of 18.4.1. Brad - The mantis "Additional info" section refers to sv-178702.html Neil - We think it is a typo. The mantis history doesn't show it Stu - Do the minutes mention it? Shalom - There was an approved friendly amendment ("shall be illegal") - That update is not in the current proposal. Move: Stu - send mantis 1787 back to the svec for updates Second: shalom Passed unanimously 1777 Clarification of 1800-2005 section 18.4.1 Approved on April 30, 2007 unanimously. [Feedback from Shalom] The proposal for 1777 is not updated to Draft 3a. It refers to 18.4.1 in 1800-2005, which is apparently 18.5.1 in Draft 3a. The struck-out text starts with "The goto repetition with nonconsecutive occurrence", but I don't see the word "goto" in the original. I don't know if there are other differences. The capitalization of 'goto' in the proposal is inconsistent. In Draft 3a, it seems to be consistently uncapitalized. [Feedback from Brad] Also, the intransitive "will increment" is inconsistent with the rest of the paragraph that says bins are "incremented". And, it's a little odd that it says "Next, ..." regarding what happens on the 15th-18th samples, and only after that talks about what happens on the 12th-13th samples. Brad - We are editing proposals Shalom - Make sure that they are updated with respect to draft 3a - The Champions shouldn't be doing this 1736 Example in 12.4.2 has dynamic array packed. Approved on April/24/2007 unanimously by email vote. [From Shalom] Proposal is OK. Would be nice to change xref in Mantis summary line to 13.5.2. 1723 Size method for associative arrays Approved on June/11/2007 with 2 No votes: Cliff - doesn't think of size as being the number of elements, thinks of it as the address spanned, encompassed by elements already allocated. Stu - no change needed [Feedback from Shalom] The reference should be to 7.10.1 instead of 17.10.1. Grammar: "The syntax for the num() and size()methods are as follows:" should be "The syntax for the num() and size()methods is as follows:" 1680 "literal string" should be "string literal" Approved on April/24/2007 unanimously by email vote. [Feedback from Shalom] 1680 was not updated to Draft 3a. There are text as well as section number issues. 1655 Coverage Calculation Corner Case Crumminess Approved on April 30, 2007 unanimously. Shalom had a lot of feedback. 8/13/07 1. The title line of the proposal says 18.10, but it should be 18.11 (or 18.6 and 18.11). 2. Similarly, the line "ADD the specified blue text 18.5 as follows:" should refer to 18.6. 3. "intersect cross-products specified" should not be hyphenated, for consistency with LRM. 4. In "since the explicitly declared bins covers all cases for which i == 0", "bins" should be "bin". 5. "ADD the specified blue text to 18.5.1 as follows:" should refer to 18.6.1. 6. In "Additionally, the cross retains those automatically-generated bins that represent cross-products not intersecting any of the user-defined bins. There are 6 of these: <b1,a3>, <b1,a4>, <b3,a3>, <b3,a4>, <b4,a3>, and <b4,a4>," "cross-product" should not be hyphenated, and the cross products should be specified with a before b, e.g., <a3,b1> instead of <b1,a3>. 7. "MODIFY 18.6 as follows:" should be 18.7. 8. "In Table 18-29, the alignment of the cell bodies in the top three rows is not consistent with the rest of the table. The six inconsistent cells should be modified to match the rest of the table" looks already fixed in Draft 3a. 9. "MODIFY 18.10 as follows:" should be 18.11. 10. "d) If get_coverage or get_inst_coverage are called with two arguments, zero is assigned to both arguments; the numerator and denominator." should be "is called". Yes, I know the mistake is in the existing text. 11. "In consistency with the above behavior, $get_coverage shall return a value of 100.0 if called on a design that has no constructed covergroups, or if called on a design in which all covergroups have a weight of 0." "In consistency with" sounds strange. "Consistent with" sounds better. "$get_coverage" should be "get_coverage()"? What is a "constructed covergroup"? The term does not seem to appear in the LRM. Is there a non-constructed covergroup? If not, why not just 'covergroup'? 12. "MODIFY 18.10.1 as follows:" should ne 8.11.1. 13. "ADD the following text at the very end of 18.10.2:" should be 8.11.2. 14. "In case the denominator of the cross coverage calculation formula has a value of zero:" - Better is "If the denominator ..." 15. "d) If get_coverage or get_inst_coverage are called with two arguments, zero is assigned to both arguments-the numerator and denominator." - should be "is called". 1615 can processes spawned by functions execute blocking statements? Approved on October/23/2006 unanimously. This proposal wanted to add 11.6.1 (in 1800-2005) after 11.6. The text from 11.6 is now in 9.3.2. I don't like 4th level subclauses (9.3.2.1), so I am not sure where and how to place this. The following sentence seems hard to understand: "Calling a function that executes a fork..join_none block shall be illegal in any context in which a side effect is disallowed or any context other than procedural code originating in an initial block." I think the following would be simpler: "Calling a function that executes a fork..join_none block shall be legal only in procedural code originating in an initial block and illegal in any context in which a side effect is disallowed." (Is there a difference between "originating in an initial block" and "in an initial block"? If so, are readers going to understand the difference?) Is the following sentence needed: "Implementations shall issue an error either at compile time or run time when they have determined the illegal condition.?" The function declaration is called start_check, but the function calls start_checks. 1612 Timeunits decls don't make sense in class decls (BNF) Approved on May 2,2007 unanimously by email vote. [Shalom] reference to Syntax 7-1 should be 8-1. Footnote 17 should be footnote 16. 1609 import statements should not be allowed in class scopes Approved on June/25/2007 unanimously. Shalom - 25.2 should be 25.3. 1605 Clarification of mailbox/semaphore constructor Approved on October/23/2006 unanimously. Shalom - The references should be 15.3.1 and 15.4.1. 1580 Access to interface objects via virtual interface Approved on May 2, 2007 unanimously by email vote. [From Shalom] 20.9 should be 24.10. "Access to all objects declared in an interface is always available by hierarchical reference, regardless of whether the interface is accessed through a port, through a virtual interface, or if there are modports to restrict those access mechanisms." I think "if" should also be "whether". "When an interface is connected with a modport in either the module header or port connection, access through a port or through a virtual interface is limited to only objects listed in the modport, for only types of objects legal to be listed in a modport (nets, variables, tasks, functions, and clocking blocks). All other objects may be referenced." I find this wording very unclear. It is unclear what "all other objects" refers to, and it is unclear how they may be referenced. The original text had, "All objects are still visible by hierarchical reference." This seemed to repeat the first sentence, "Access to all objects declared in an interface is always available by hierarchical reference," and if so, to be redundant. Does this proposal intend to change the meaning of the last sentence? I also find the difference between "module header" and "port connection" unclear, since I think of port connections as part of the module header. 1556 in-line static variable initialization - require keyword static? Approved on June/11/2007 unanimously. 1545 13.12.1: $urandom example error Approved on October/9/2006 unanimously. 1480 method_call_root BNF should use primary, not expression Approved on October/9/2006 unanimously. 1459 Mailbox 'new' method should never return null Approved on September/11/2006 unanimously. 1427 dynamic_array_new Approved on April 30, 2007 unanimously. 1371 Semantic of program block $exit Approved on June/25/2007 unanimously. 1336 Rules for allowed statements in a function Approved on Jan/22/2007. unanimously. 888 foreach identifiers are too restrictive Approved on October/23/2006 unanimously. 594 15.8 special syntax for accessing interfaces through clocking block Approved on October/9/2006 unanimously. Move: Stu - send all of these back to svec and Neil put them in the Feedback state and the svec update them to draft 3a. (Mantis items 1787 through 594 in this list) Second: Shalom Passed unanimously From sv-cc Mantis items with proposals that have been approved: 1741 1800-2005 Section 27.50 Issues with foreach diagram The SV-CC approved this proposed change on 06/06/2007 (unanimous). [email from Brad] Regarding http://www.eda-stds.org/svdb/view.php?id=1741 , not necessarily an objection, but ... "An unnamed begin or unnamed fork shall be a scope if and only if it contains local variable declarations." Yet it's still true, isn't it, that the unnamed begin below is not a scope and that a hierarchical reference to BLK.v from outside the unnamed begin would be legal? begin begin : BLK var v = 1'b1; // This decl is not contained in the unnamed begin? end end [email response from Shalom] I think that this is consistent. Brad - ok, as long as that example is ok (can refer to var v with a hierarchical reference). He thought that this example may have pointed out a problem. - The proposal says it shall be a scope if it contains local variable declarations. Today the unnamed block is not a scope. Fm - In the example it contains a named block. Why is it just a local variable declaration that would make it a scope? Stu - Does it make the unnamed block a scope? Dave - Thought that there would be a hidden scope if an unnamed block had a variable declaration. Fm - There could be a type declaration as well. Item d) of the proposal says an unnamed block will have tool dependent names. Stu - This is also a question for the sv-bc Also ask about a named block without a local variable. Move: Stu - reject the proposal for mantis 1741 and send it back to svcc for clarification on type declarations and parameters. The sv-cc also needs to contact the svbc. Second: ???? Passed unanimously 1751 Clarify vpiParent for part selects This was PASSED by the SV-CC on 3/14/2007 (unanimous). Dave Rich - Needs update for P1800/D3 Dave - Not sure where this one goes within the LRM. Move: Stu - send the proposal for mantis 1751 back to the svcc. Seems to be 36.50, but we aren't sure. Also do they still want to use the reg data type (logic is used in most places today in the LRM) Second: Dave Passed unanimously 1766 VPI Nets object model shows 1-to-many for vpiLeftRange This was PASSED by the SV-CC on 3/28/2007 (unanimous). Dave Rich - Now 36.15 Stu - ok Move: Stu - approve the proposal for mantis 1766 Second: Shalom Passed unanimously 1859 Redundant DPI imports/exports section This was PASSED by the SV-CC on 06/20/2007 (unanimous). dave - looks ok Stu - The editor flagged two sections of the LRM that seemed to be the same, this mantis item removes the redundant section. Move: Stu - accept the proposal for mantis 1859 Second: Dave Passed unanimously Mantis items that have been determined to be duplicates of others 793 29.4.3 vpiAssertVacuousSuccessCovered in include file see 1599 (unanimous) Dave - not in the relationship section Move: Dave - approve next 4 as duplicates Second: Stu Passed unanimously 1579 was resubmitted as 1603 due to a mantis problem with 1579 see 1603 (unanimous) 1628 No file or line number for vpiClassObj see 741 declared to be a duplicate of Item 0741 on 06/06/2007 (unanimous). 1654 vpiConstraintItem not defined by sv_vpi_user.h see 754 declared to be a duplicate of Item 0754 on 06/06/2007 (unanimous) Mantis items that won't be fixed or don't require a change 1613 Should a[0:0] be considered a vector or scalar? no change required Moved to declare as NOT A BUG on 10/11/2006 (unanimous) Move: Francoise - approve mantis 1613 and 1834 as no change required Second: Shalom Passed unanimously 1834 JEITA: PLI tf_ and acc_ routines in an appendix won't fix 06/06/2007 moved to declare this Item to be "not a bug" (unanimous). From sv-ac 1729 Introduce immediate assume and cover statements Resolved by e-mail ballot on 2007-04-30, 9y/0n/0a Updated for draft 3a July 19 Brad - The paragraph after syntax 16-1 was updated this morning. It didn't take into account assume or cover The following set of changes need to be made to this proposal: - 16-1 syntax was changed since this mantis item was updated action_block ::= else <--- is now null - The () in the syntax box should be in red - On bottom of page 2 - example - assume and cover need bolding - Add a note to the editor in the proposal to not change the action_block syntax. - Syntax A.6.10 immediate_assert_statement ::= <--- use a different name here - Should be more generic since it has 3 choices Dave suggests immediate_assertion_statement. immediate_assert --> immediate_assert_statement immediate_assume --> immediate_assume_statement immediate_cover --> immediate_cover_statement Compare this to the syntax in A.2.10 - Syntax box on page 2 - has different set of blue items vs. A.6.10 - 16.3 , 2nd paragraph is new -- needs to be blue , 4th paragraph assert should be bold - Paragraph after 16-1 - should be bold for assert. 2nd paragraph Stu thinks this sentence might be ok. - make bolding consistent for this whole section - there seem to be some grammar errors as well. Move: Stu - send the proposal for mantis 1729 back to the svac for updates Second: Shalom Passed unanimously 1730 Allow literal sequence and property actual arguments Resolved by ballot, 2007-04-30, 7y, 0n, 2a Updated for draft 3a July 24 Brad - The proposal was updated to draft 3a this morning stu - ok Brad - there is a note at the top about syntax ambiguity Sur - has to do with substitution Brad - like a macro for this situation - he doesn't quite follow it, but will take the committees word on it - are there any examples on this? Move: Surrendra - approve the proposal for mantis 1730 Second: Brad Passed unanimously 1734 Incomplete fix to Annex F in 0805. Resolved by e-mail ballot on 2007-04-30, 7y/0n/2a Updated for draft 3a July 19 Neil - the fonts aren't coming up properly Stu - looks ok in word, ok from editor point of view Dave - uploaded a pdf version of the proposal Sur - disable only allowed at front, text was updated but not the formal writeup. This updates the formal. Move: Surrendra - move to approve proposal for 1734 Second: Brad Abstain: Brad - not qualified to review this proposal Francoise - same reason Passed with two abstains 1735 Incomplete fixes from 0928 Resolved by email ballot, 2007-03-14, 9 yes, 0 no Updated for draft 3a July 21 stu - ok Move: Brad- approve the proposal for mantis 1735 Second: Surrendra Passed unanimously 1361 need a way to control execution of action blocks Passed by e-mail ballot on 2007-07-31, 7y/0n/1a Friendly amendment added during e-mail ballot was confirmed by voice vote on 2007-08-07, 8y/0n/0a. Dave - was the friendly amendment in bug note added? Neil - we think so. Dave - now that there is an action block for assume and cover applies to them as well? Sur - thinks so. just for concurrent assertions Brad - the other one doesn't apply to immediate. - contingent on 1768 Stu - seems ok with it - can ask committee for guidance if necessary Shalom - 1768 deletes some sentences. Stu - 1768 adds new constructs Move: Stu - approve the proposal for mantis 1361 Second: Surrendra Passed unanimously 1601 new keyword for untyped formal arguments Passed by e-mail vote on 2007-07-31, 8y/0n/0a <see champions minutes of 7/26> 1681 Introduce global clocking Passed by e-mail vote on 2007-07-31, 8y/0n/0a. Dave - doesn't discuss what global clock is with respect to compilation units - there is no concept of globals in SystemVerilog Shalom - time precision is similar Dave - all precisions are taken into account - specifying a global in this mantis item - it should be a tool option Shalom - the idea of a global clock - can sample any signals Intuitively understands the need for it Neil - used for formal tools FM - strange that it is global and needs to be in a module, it should be in compilation unit space Stu - not sure it fits in with the general usage of the language. The lrm is based on event based simulation Dave - his issues were brought to the attention of the committee - how does synthesis handle clocks? Brad - they are inferred, or use pragmas Shalom - if in a package would need to be imported Neil - just for formal tools Sur - yes, but also want the same semantics for simulation Today there is a sim, fv mismatch due to no global clock FM - not sure why need this global thing, we already have clocking blocks. Sur - the issue comes when there are multiple clocks Stu - The proposal says that global clock is for the design. Can the testbench use the global clock? (proposal seems to not say) - proposal shouldn't use the term design if it isn't clear AI/Neil - take off the agenda and discuss next time. need more people to discuss it off-line 1722 there exists bind inconsistencies between the BNF and the text Passed by e-mail vote on 2007-07-31, 8y/0n/0a Dave - ok Shalom - doesn't look controversial - now applies to more than just assertions - spelling error - 22.10 (auxiliary has only 1 l) more than one occurrence (at the end) Item 1) if the... capitalize the if identifier is spelled wrong (3 times) Stu - frame spell check should flag it Move: Stu - approve the proposal for mantis 1722, correct spelling and capitalization problems Second: Shalom Passed unanimously 1768 need to define how to interpret whether the argument to cover is a property or sequence Passed by e-mail vote on 2007-07-31, 8y/0n/0a. Voice vote on 2007-08-07 to confirm friendly amendment suggested during e-mail ballot, 8y/0n/0a. Shalom - missing a friendly amendment? Dave - ok Stu - has changes dependent on 1599 Move: Stu - send mantis item 1768 back to the svac so that they can add the missing friendly amendment Second: Shalom Passed unanimously [Discussion after the vote - some people dropped off the line already] Shalom - it looks like the amendment is actually there. Stu - needs to do them together From sv-bc Move: Dave - approve 1200 through 1831 Second: Brad Abstain - stu (changed to approve later in the meeting) Passed unanimously Stu - has not reviewed all of them Dave - the editor has a way to send back any mantis items with issues Karen - we can pass contingent on Stu review between now and P1800. V-1364 ------- 0001200 0001257 0001388 Shalom - the proposal should be deleted as no longer relevant resolution is to close as already fixed. doesn't need to go to the editor 0001499 0001505 0001644 Shalom - the proposal should be deleted as no longer relevant 0001746 0001748 0001783 SV-BC ------- 0001400 0001497 0001561 0001562 0001589 0001597 0001606 0001620 0001660 0001666 0001673 0001724 0001749 0001762 0001788 0001807 0001821 0001825 0001831 3. Meetings Sept 5 9-11PST <---- next meeting (note the change in date) List of action items from this meeting -------------------------------------- 1. Neil - email to committees on schedule and recommend not hold off until the end 2. Neil - move mantis items with friendly amendments to the feedback state 3. Neil - send feedback to the svec on which mantis items have changes that need to be made. 4. Neil - send feedback to the svec on which mantis items were sent back from the champions without being reviewed in detail. 5. Neil - check svec minutes to see if there is a problem with 1787 6. Neil - send 1741, 1751 back to the sv-cc for clarifications 7. Neil - send 1729 back to the sv-ac for updates 8. Neil - send feedback to svac - add an example for the situation in 1730 9. Neil - add 1681 to the next meeting agenda. The Champions wanted time to discuss this with others before voting. 10. Neil - have the sv-ac fix the spelling and capitalization errors in 1722 11. Neil - email vote on 1768, if the friendly amendment is there...Received on Sat, 18 Aug 2007 19:17:47 -0700
This archive was generated by hypermail 2.1.8 : Sat Aug 18 2007 - 19:18:23 PDT