Attached is a detailed summary of the results of the last three meetings of the Champions. This will be the basis of discussion in the next P1800 Working Group meeting. Neil -- --------------------------------------------------------------------- Neil Korpusik Tel: 408-276-6385 Frontend Technologies (FTAP) Fax: 408-276-5092 Sun Microsystems email: neil.korpusik@sun.com --------------------------------------------------------------------- -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. P1800 memobers, The Champions have met three times since the last meeting of the P1800 Working Group. July 26, 2007 August 8, 2007 August 15, 2007 Below is a list of the mantis items that the Champions have approved. Some of them have been approved as specified in the latest mantis proposal. Some of them have been approved with friendly ammendments. Others have been sent back to the committees for updates. There is one mantis item that has been rejected by the Champions. Stu has requested that the Working Group not pass any of those mantis items that have friendly ammendments unless all of those friendly ammendments are made prior to the next Working Group meeting. All of these resolutions have been approved unanimously by the Champions, unless otherwise indicated. There is one set of mantis items from the svbc that I still need to provide the technical committee vote results for (mantis 1200 thru 1831 shown below). I will provide that on Monday. Neil Mantis items passed by the Champions as shown in the latest proposals ---------------------------------------------------------------------- Id Summary 1385 Please document compatibility issues between 1364 and 1800 VPI svcc approved unanimously 06/20/07 - (with friendly amendments) 1460 Allow actions within assume property statement svac approved unanimously (only 8 of 10 voted) 1674 Context value functions $inferred_clock, $inferred_disable, $inferred_enable svac approved unanimously by email vote 06/25/07 1677 Add $changed sampled value function svac approved unanimously - 02/06/07 meeting 1004 5.1.13: Zero fill in ?: even if signed or x/z svbc unanimously approved 06/25/2007 1101 17.1.1: not clear how "\a" is interpreted (in $display) svbc unanimously approved by email vote 06/11/2007 1143 allow unsized numbers and integer variables in concatenations Resolution: no change required 06/11/2007 Opposed: Shalom (would be a useful capability in concatenations) Don (wants integer to be recognized as a 32-bit value) Shalom - His wasn't a strong opposition. - He made a correction to an inaccurate bugnote for this item. Passed in the Champions meeting, with one abstain. Abstain: Shalom - same reason he opposed in svbc 0227 Ambiguous phrase "packages must exist" svbc Unanimously approved 6/25/2007 Stu was unable to attend the meeting in person, but he did provide input to the committee before the meeting was held. He voted in favor of this mantis item but offered the following input: "I do not like the change because it requires file order dependency in compilation. I assume the BC has discussed this and decided it is not practical to avoid file order dependency. The change does fix the ambiguous wording in the current LRM, even if I don't like the fix." 0915 Size wrong in comments of an example of 4.10 svbc Unanimously approved 6/25/2007 0918 'medal' reference refers too far back in text svbc Unanimously approved 6/25/2007 1064 Multi-line string literals? svbc Unanimously approved 6/25/2007 Brad - Affects backward compatibility? Shalom - Doesn't change what is in the standard - Some simulators behave differently - Vendors agreed to match what was in the standard. Checks of regression databases didn't find any user examples. - Currently defined LRM is preferable even if tools need to be changed. - Some tools were not following the text in 1800-2005 1859 Redundant DPI imports/exports section svcc This was PASSED by the SV-CC on 06/20/2007 (unanimous). 1730 Allow literal sequence and property actual arguments svac Resolved by ballot, 2007-04-30, 7y, 0n, 2a Updated for draft 3a July 24 1734 Incomplete fix to Annex F in 0805. svac Resolved by e-mail ballot on 2007-04-30, 7y/0n/2a Updated for draft 3a July 19 Abstain: Brad - not qualified to review this proposal Francoise - same reason Passed with two abstains 1735 Incomplete fixes from 0928 svac Resolved by email ballot, 2007-03-14, 9 yes, 0 no Updated for draft 3a July 21 1361 need a way to control execution of action blocks svac 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. ++++ Start of the list of approved items from the svbc ++++ Move: Dave - approve 1200 through 1831 (all from the svbc) Second: Brad Abstain - stu (changed to approve later in the meeting) Passed unanimously 0001200 0001257 0001388 Shalom - the proposal should be deleted as no longer relevant 0001499 0001505 0001644 Shalom - the proposal should be deleted as no longer relevant 0001746 0001748 0001783 0001400 0001497 0001561 0001562 0001589 0001597 0001606 0001620 0001660 0001666 0001673 0001724 0001749 0001762 0001788 0001807 0001821 0001825 0001831 ++++ End of the list of approved items from the svbc ++++ Mantis items passed by the Champions after making friendly ammendments ---------------------------------------------------------------------- Id Summary 985 cbSizeChange for queues too? svcc approved unanimously 10/25/06 (wasn't marked as passed until recently) 27.14 is now 36.16 - Friendly amendment to update the section number 1603 Unused vpiMultiArray declaration in vpi_user.h svcc approved unanimously Change for 1800-2008 Annex L - Friendly ammendment to update section number The change should be to Annex L (not annex G) Possible backward compatibility issue. svcc checked with vendors, not yet implemented. not covered by 1385 No one could have known where it was used. 1614 P1800-2005: 27.52 no expr for disable fork objects svcc approved unanimously 01/03/07 27.52 is now 36.67 - Friendly ammendment to update section number 1631 P1800-2005 27.14 note k has an error svcc approved unanimously 01/03/07 27.14 item k) is now 36.16 item 11) Friendly ammendment to update section number 1632 P1800-2005 sections 27.14 note k and 27.22 note f are incompatible svcc approved unanimously 01/03/07 27.22 is now 36.26 - Friendly ammendment to update section number 1664 IEEE 1800-2005 27.7 Note 'e': First sentence should be rewritten svcc approved unanimously 01/03/07 27.7 item e) is now 36.9 item 5) Friendly ammendment to update section number 1669 P1800-2005 Sections 27.34 and 27.36 commas are inconsistent svcc approved unanimously 01/03/07 with friendly amendments 27.34 item b) is now 36.45 item 2) Friendly ammendment to update section number spelling error - Friendly ammendment to add note to the editor an extra comma - Friendly ammendment to add note to the editor 1684 vpiParent clarification needed for complex var/net objects svcc approved unanimously 02/16/07 - with a friendly amendment 27.14 item z) is now 36.16 item 29) 27.13 item ab) is now 36.15 item 28) Friendly ammendment to update section numbers keywords need to be bolded - Friendly ammendment 1699 1800-2005+ draft 3 sections 36.34 and 36.68 problem with vpiReturn svcc approved unanimously 06/20/07 36.34 - should be 36.51 36.68 - this section number is ok Stu will change ### to an available number and add a margin note. 1700 vpiTimeConst and vpiNullConst have the same value svcc approved unanimously 01/03/07 This change is now in Annex M Friendly ammendment to update section number 1716 Clarify handling of DPI formals/actuals with rand/randc qualifier svcc approved unanimously 02/28/07 Annex F.5 is now Annex I.5 Friendly ammendment to update section number 1550 $sampled function definition svac approved unanimously 02/14/07 7 yes, 3 not voting Friendly amendments: - Add a description of the deprecated syntax to Annex C.2 The deprecated syntax should only appear in Annex C.2 and not in sub-clause 16.8.3 - Remove the following sentences from 16.8.3 "The function $sampled does not use a clocking event, although one can be optionally provided. The optional clocking event is ignored, and its use is deprecated" - Change the syntax for $sampled in 19.11, 16.8.3 such that the argument clocking_event is not shown. 1567 22.9: in Syntax 22-7, should be no semicolon svac 2006-12-08. Unanimously approved. Friendly amendments: Change the proposal to make it more obvious what is being changed. - The s that is being removed should have a strikethrough and be in red - The ; being removed should have a strikethrough on it 1789 Clarification of string behavior svec Passed unanimously by email vote June 22, 2007 Friendly ammendments: - "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'. 1766 VPI Nets object model shows 1-to-many for vpiLeftRange svcc This was PASSED by the SV-CC on 3/28/2007 (unanimous). Now section 36.15 1722 there exists bind inconsistencies between the BNF and the text svac Passed by e-mail vote on 2007-07-31, 8y/0n/0a Friendly ammendments: (correct the spelling and capitalization problems) - spelling error - 22.10 (auxiliary has only on 'l') more than one occurrence (at the end) - Item 1) if the... capitalize the if identifier is spelled wrong (3 times) Mantis items sent back to the committees for updates: ----------------------------------------------------- 1591 17.7.3, 22.9: $past syntax not precise svac approved unanimously by email vote 02/14/07 Updates required: Has similar issues as those flagged for 1550. - Update the part about $sampled (see feedback for mantis 1550) - Rename or remove old proposals. 1704 need to specify behavior of attached subroutine on empty seq match svac approved unanimously by email vote 03/01/07 Three changes need to be made: - "must not admit" should be "shall not admit" - Get rid of commas in the next to last sentence. - When used on a sequence that admits an empty match an error message shall be issued. [The sv-ac should determine the appropriate wording for this error case.] 1601 new keyword for untyped formal arguments svac Passed by e-mail vote on 2007-07-31, 8y/0n/0a This is an enhancement Dave - I am opposed to this enhancement at the current time. It is unfortunate that we ever allowed un-typed formals. The language should be fixed properly so that un-typed formal are obsolete rather than allowing them to be mixed with typed formals. - basically changing the language to be more strongly typed makes things more obfuscated to mix them. - looks like the new set of people are in favor of a new approach and are rewriting the language. - using 'context' as a new type Brad - a new type that means any type. Dave - this proposal could affect future changes with respect to a variable number of arguments. - untyped formals weren't well thought out originally. - is there a real need to mix typed and untyped formals? sur - recursive properties can be an issue. You need to maintain the type in passing values between properties. - you don't always know what you are passing to an assertion - there were a lot of discussions on this in the committee Dave - can put the untyped arguments first. The only reason for this proposal is to allow them in the middle. Doesn't see the ordering of args making a strong case for this. stu - doesn't like adding new keywords using the word context in a different way here (not good either). Dave - we need untyped arguments in other parts of the language. we need to make sure that we are ok with whatever is allowed in svac. fm - doesn't like context Brad - 'untyped' could possibly be used in place of context Dave - still opposed, even by using the new keyword untyped. by rejecting this proposal, only effect is to force untyped to be first. Not a major restriction. Sur - the proposal makes it more clear that they are untyped. Dave - keyword versus good idea. Stu - send it back to use untyped and request a justification for proposal Move - Stu - send 1601 back to the sv-ac to use 'untyped' in place of 'context' and request a justification for the proposal Second - Dave Abstain - sur - not convinced of reasons for rejecting it. Passed with one abstain in the Champions meeting. 1648 Default reset for assertions (default disable) svac unanimously passed by email vote 06/25/07 Dave - I am against this enhancement at the current time. I believe this feature will be useful in a wider context, such as covergroups, but the committees have not had time to study this. If we add this feature now, it will be harder to address the other areas due to backward incompatibilities. For example, suppose the sv-ec decides that default disable should also disable sampling of covergroups. We can't add that capability later; we must look at all the other areas that could be affected. But due to schedules and merge activities, the other committees have not been able to investigate. Fm - agrees that there could be backward compatibility issues. Brad - ask svec - if covergroups should use this as well? Dave - there may be other places that could use it as well. Sur - can't have disable properties on sub properties. Stu - doesn't think everything is being considered. Same properties can have different behavior depending on how used. Top-level versus not top-level (e.g. rule b on first page). Sur - disable applies to the assertion not the property itself. Issues: Brad - The bnf shouldn't be in the text. Fm - 3rd paragraph under syntax box, part about "...on the position of...", doesn't need to say it. "The scope of the... " isn't clear. - There are issues in the other 2 paragraphs as well. stu - Wording of first paragraph - should be reworded "One can specify..." --> "A default disabling condition may be..." Move: Stu - send 1648 back to svac with this set of 3 concerns. Second: Dave Passed unanimously <A large number of mantis items was sent back to the svec as a group due to the large number of issues found by the Champions.> ++++ Start of the list of items from the svec ++++ 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 1787 LRM needs to discuss transition bins of length 1 svec Approved on April 30, 2007 unanimously. 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. 1777 Clarification of 1800-2005 section 18.4.1 svec 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. svec 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 svec 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" svec 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 svec 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? svec 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) svec 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 svec Approved on June/25/2007 unanimously. Shalom - 25.2 should be 25.3. 1605 Clarification of mailbox/semaphore constructor svec 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 svec 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? svec Approved on June/11/2007 unanimously. 1545 13.12.1: $urandom example error svec Approved on October/9/2006 unanimously. 1480 method_call_root BNF should use primary, not expression svec Approved on October/9/2006 unanimously. 1459 Mailbox 'new' method should never return null svec Approved on September/11/2006 unanimously. 1427 dynamic_array_new svec Approved on April 30, 2007 unanimously. 1371 Semantic of program block $exit svec Approved on June/25/2007 unanimously. 1336 Rules for allowed statements in a function svec Approved on Jan/22/2007. unanimously. 888 foreach identifiers are too restrictive svec Approved on October/23/2006 unanimously. 594 15.8 special syntax for accessing interfaces through clocking block svec Approved on October/9/2006 unanimously. ++++ End of the list of items from the svec ++++ 1741 1800-2005 Section 27.50 Issues with foreach diagram 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 svcc This was PASSED by the SV-CC on 3/14/2007 (unanimous). 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 1729 Introduce immediate assume and cover statements svac 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. 1768 need to define how to interpret whether the argument to cover is a property or sequence svac 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? Stu - has changes dependent on 1599 Send mantis item 1768 back to the svac so that they can add the missing friendly amendment [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 Mantis items rejected by the Champions -------------------------------------- Id Summary 1466 shortcuts for delay and consecutive repetition svac Resolved by voice vote on 2007-05-01. 7y/0n/1a Dave - I am opposed to this enhancement at the current time for the following reasons: 1. This is not Verilog-like. Use of a range specification [n:m] in Verilog is quite common and having a single character does not fit with rest of the language. Also, '?' means 'z' in Verilog 2. Other parts of the language use similar range specifications (Queues and coverage transitions). If we must have these shortcuts, shouldn't they be uniformly applied? In then end, I don't think the 2 keystroke shortcut is worth the instability. Dave - Steven Sharp also questioned the usefulness of this enhancement. Shalom - the desire was for PSL and SystemVerilog to be more similar Dave - It is hard to put a focused effort on this type of issue. This is an enhancement. We need more time to work out the issues. Fm - agrees with Dave. If just a shortcut, we don't need it. stu - You lose code documentation '?' in a UDP means don't care, ==? wildcard Dave - If it was a PSL conflict that would be a stronger reason to add it Surrendra- users want concise syntax for assertions. Some users really want it Shalom - n is used for an unpacked array size - people want to take PAL and easily convert it to SystemVerilog - ? is not in PSL Dave - objected to that as well. Brad - shortcuts are easier to read. Francoise - understands the long-hand easier Dave - 1,$ is a pop operation for a queue - covergroups may also be inconsistent. - If we allow shortcuts they should be uniformly applied throughout the language. stu - Should other committees have a chance to comment on this? Shalom - Opposite argument was used for the 'let' construct for assertions Move: Brad - approve the proposal for mantis 1466 Second: Surrendra Abstain: Shalom - has no strong opinion either way. Oppose: Dave - see above reasons Francoise - should be similar to verilog, e.g. designers. We don't need a new syntax. Stu - 1. no added capability 2. Obfuscates the code - means different things in different contexts. Motion failed Mantis items that should be closed -------------------------------------- Id Summary 1543 Meaningless sentence in 17.15 and Annex H svac Unanimously approved 2006-12-08 Champions think the changes are already in the lrm. Should be closed 999 check index Index for 1364 LRM On March 13, 2006, the SV-BC voted to resolve this issue without addressing the specified items. The vote was not unanimous: For: Francoise, Mark, Doug, Gordon, Dave, Stu Opposed: Steven (no issue for index in SV-BC) Shalom(no issue for index in SV-BC) Brad(no issue for index in SV-BC) Karen (leave it the way it is) A new svdb entry is to be created requesting an accurate, updated index in the next draft of the 1800 LRM, especially one merged with 1364. Issue 1643 has been filed requesting an index in the next draft of the P1800 LRM. Shalom - Back then people didn't want the issue to be lost for 1800 - The new issue was opened. 1153 parameterized task/function extensions svbc duplicate of 696 - unanimously agreed Shalom - They were filed in parallel since 1800 and 1364 were separate. - When the groups the were merged it became one issue. 1198 Support a container to define how to interface to a set of signals. svbc already covered by lrm - unanimously Shalom - It was filed on 1364 but was already in the 1800 LRM. 0965 Name from example should use constant-width typeface (6.3.2.1) svbc Unanimously approved by email vote 06/11/2007 Resolution: no change required 1297 genvar clarification svbc Proposal approved unanimously in the 9/21/06 P1800 WG Meeting. The editor wasn't sure what changes were required [Mantis "Additional information" field] During the March 13, 2006 SV-BC meeting this issue was unanimously voted as resolved because it was deemed addressed in 1364. This resolution means that no further action is required by the editor. 793 29.4.3 vpiAssertVacuousSuccessCovered in include file see 1599 svcc passed unanimously - duplicate 1579 was resubmitted as 1603 due to a mantis problem with 1579 see 1603 svcc unanimous - duplicate 1628 No file or line number for vpiClassObj see 741 svcc declared to be a duplicate of Item 0741 on 06/06/2007 (unanimous). 1654 vpiConstraintItem not defined by sv_vpi_user.h see 754 svcc declared to be a duplicate of Item 0754 on 06/06/2007 (unanimous) 1613 Should a[0:0] be considered a vector or scalar? no change required svcc Moved to declare as NOT A BUG on 10/11/2006 (unanimous) 1834 JEITA: PLI tf_ and acc_ routines in an appendix won't fix svcc 06/06/2007 declare this Item to be "not a bug" (unanimous). Mantis items that the Champions wanted more time to discuss with others ----------------------------------------------------------------------- 1681 Introduce global clocking svac 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 clearReceived on Sun Aug 19 16:25:49 2007
This archive was generated by hypermail 2.1.8 : Sun Aug 19 2007 - 16:25:55 PDT