There was a typo on the date shown in the minutes. It is now fixed. Neil -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. Champions meeting minutes of August 8, 2007 8am - 10am 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. - Stu Note: Stu was in Japan during our meeting. He sent input to the committee ahead of time mentioning that he had reviewed all of the mantis items from the Editor's standpoint and did not have problems with any of them. 1. Review IEEE patent policy http://standards.ieee.org/board/pat/pat-slideset.ppt Move: Dave - assume that the patent policy was read Second: FM 2. Mantis items From the sv-ac 1674 Context value functions $inferred_clock $inferred_disable $inferred_enable approved unanimously by email vote 06/25/07 Stu - ok Dave - I am opposed to using system functions that represent syntactic sugar. I think syntax is better at representing syntactic sugar. For example "clk = default clocking" - The SV-AC is adding a lot of system functions. - Seem to not be putting enough thought into language space solutions. - Not against the feature itself. Shalom - Dmitry sent email addressing Dave's feedback. "System functions are widely used in SystemVerilog for this purpose. $typename is just one example." Dave - They are only usable in a property, and only as default argument of a property. - Has suggested the possibility of using a method. FM - Not sure that a method would be a good approach Maybe ok if associated with a property. Shalom - Restricting enhancements to their part of the language. Dave - This one is fairly isolated - doesn't feel too strongly about it - This is just one example of their use of system functions properties will end up looking like a bunch of system functions - If PLI is to override these tasks, how would it access that info? FM - PLI can usually override them, an advantage of system functions? Dave - Not using a system function because they need it, using it more like a language construct. Only meaningful in a particular position. Should be using grammar for this. Shalom - Can avoid new keywords this way. Is there really a problem with adding new system functions? - They are thinking about it as a query. - Elaboration time system functions Dave - $typename is another one - The sv-ec would typically use a method or the :: syntax - A method of the property would be possible. Brad - This proposal is similar to $bits Shalom - These are context dependent - more like 'this' Sur - could be part of a context object FM - Thinks system function is ok - It is unfortunate that they are only for properties. Shalom - sv-ac thought it would be easier if they restricted it to properties Dave - ## can refer to a clocking event. Shalom - That is an event control - These are for binding purposes, explicit or inferred Dave - withdrew his objection Move: Brad - approve the proposal for mantis 1674 Second: Surrendra Passed unanimously 1677 Add $changed sampled value function approved unanimously - 02/06/07 meeting Shalom - Just adding another system function to an existing set of system functions. Brad - It is the opposite of $stable. Move - Francoise - approve the proposal for mantis 1677 Second - Shalom Passed unanimously 1704 need to specify behavior of attached subroutine on empty seq match approved unanimously by email vote 03/01/07 Brad - "must not admit" should be Shalom - "shall not admit" Sur - a compiler could check this - drop commas in the 2nd to last sentence Dave - what does admit mean? Sur - not well defined in the LRM - means "cannot have an empty match" Brad - that word is already in the LRM - need to get a compiler error - "Shall be a compile time error..." Dave - let the committee figure out the exact language required. 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.] Move: Dave - send the proposal for mantis 1704 back to svac (3 issues) Second: Brad Passed unanimously From sv-bc V-1364 Dave - these should be changed to sv-bc 0000999 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. Move: Shalom - mantis item 999 should be closed Second: Dave Passed unanimously 0001004 5.1.13: Zero fill in ?: even if signed or x/z unanimously approved 06/25/2007 Move: Shalom - approve the proposal for mantis 1004 Second: Francoise Passed unanimously 0001101 17.1.1: not clear how "\a" is interpreted (in $display) unanimously approved by email vote 06/11/2007 Shalom - A string argument changed to a string literal argument Move: Shalom - approve the proposal for mantis 1101 Second: Dave Passed unanimously 0001143 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. - The next to last bugnote is not quite correct (3/29/07) - Unsized constants are 32 bits. Move: Dave - approve the resolution for mantis 1143 Second: Brad Abstain: Shalom - same reason he opposed in svbc Passed with one abstain 0001153 parameterized task/function extensions duplicate of 696 Shalom - They were filed in parallel since 1800 and 1364 were separate. - When the groups the were merged it became one issue. Move: Dave - approve the resolution for mantis 1153 Second: Brad Passed unanimously 0001198 Support a container to define how to interface to a set of signals. duplicate - already covered by lrm Shalom - It was filed on 1364 but was already in the 1800 LRM. Move: Dave - approve the resolution for mantis 1198 Second: Shalom Passed SystemVerilog 0000227 Ambiguous phrase "packages must exist" Unanimously approved 6/25/2007 Stu - 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. Move: Dave - approve the proposal for mantis 227 Second: Shalom Passed unanimously 0000915 Size wrong in comments of an example of 4.10 Unanimously approved 6/25/2007 Move: Dave - approve the proposal for mantis 915 Second: Shalom Passed unanimously 0000918 'medal' reference refers too far back in text Unanimously approved 6/25/2007 Shalom - an example versus the text were different Move: Francoise - approve the proposal for mantis 918 Second: Shalom Passed unanimously 0000965 Name from example should use constant-width typeface (6.3.2.1) Unanimously approved by email vote 06/11/2007 Resolution: no change required Move: Shalom - approve the resolution for mantis 965 Second: Brad Passed unanimously 0001064 Multi-line string literals? Unanimously approved 6/25/2007 Brad - affects backward compatibility? Shalom - yes - 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 Move: Dave - approve the proposal for 1064 Second: Francoise Passed unanimously 0001297 genvar clarification Proposal approved unanimously in the 9/21/06 P1800 WG Meeting. Stu 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. Move: Shalom - move that we approve the resolution for 1297 Second: Brad Passed unanimously 4. Meetings August 15 August 29 9am pst List of action items from this meeting 1. Neil - send mantis 1704 back to the SV-AC for the changes mentioned in the meeting. 2. Shalom - add another bugnote to 1143 to clarify the existing bugnotes. 3. Neil - send email to the committees on the schedule and recommend not holding off until the last minute for passing proposals. Otherwise the Champions will have a tough time completing their review in time.Received on Sat, 18 Aug 2007 19:28:21 -0700
This archive was generated by hypermail 2.1.8 : Sat Aug 18 2007 - 19:28:43 PDT