Date: 2010-11-09
Time: 16:30 UTC (8:30 PST)
Duration: 1.5 hours
Dial-in information:
--------------------
Meeting ID: 38198
Phone Number(s):
1-888-813-5316 Toll Free within North America
Local dial-in numbers
Australia, St Leonards +61.0.2862.26850
Armenia, Yerevan +374.10.492609
Canada, Mississauga +905.273.8402
Canada, Nepean +613.221.8603
Switzerland, Zurich +41.44.567.1551
Chile, Santiago +56.2.714.6898
China, Beijing +86.105.986.0609
China, Shanghai +86.212.307.2214
China, Shenzhen +8675582519810
Germany, Aachen +49.240.756.3610
Germany, Munich +49.899.932.0192
Denmark, Copenhagen +49.899.932.0192
Finland, Espoo +358 2075 78023
Finland, Tampere +358 2075 78085
France, Montbonnot +33.4.56.38.48.09
France, Montpellier +33.4.56.38.48.09
France, Rungis +33.1.45.12.06.12
France, Sophia +33.4.9723.97.06
United Kingdom, Livingston +44.15064.86027
United Kingdom, Reading +44.1189.651119
Sweden, Stockholm +49.899.932.0192
Hungary, Budapest +49.899.932.0192
Ireland, Dublin +353.1.4368831
Israel, Herzelia +972.9.9719650
India, Bangalore +91.80.401.88823
India, Hyderabad +91.40.40.331016
India, Nodia +91.80.401.88823
Italy, Agrate Brianza +39.039.6846712
Portugal, Porto +351.2204.15998
Portugal, Lisbon +351.2104.40398
Taiwan, Taipei +886.2.3725.5705
Taiwan, Hsinchu +886.3.558.1800
Japan, Tokyo +81.3.5746.1339
Japan, Osaka +81.3.5746.1339
Singapore, Singapore +65.6393.7140
South Korea, Seoul +82.2.3404.2701
Live Meeting: https://webjoin.intel.com/?passcode=3494448
Agenda:
-------
- Reminder of IEEE patent policy.
See: http://standards.ieee.org/board/pat/pat-slideset.ppt
- Minutes approval
- Email ballot results
None
- New issues
None
- Enhancement progress update
Vacuity definition (Dana's presentation)
3034: Allow continuous and blocking assignments in checkers (if time permits)
- Issue resolution/discussion
Addressing champions' feedback.
1933: 16.13.6 reference to triggered method can be improved
The proposal was opposed by the Champions in the email vote which ended
on October 30, 2010.
Shalom - Note
Please delete the proposal and clarify in a note that the vote is to close
as "no change required"
Francoise - Opposed
Section does not match the current LRM.
2252: Several symbols in Annex F are in green
The issue related to an earlier draft of the LRM, in which Annex F was different and had different subclause numbering. However, one can see that Annex F no longer has this problem.
2291: the description of $assertoff blurs assertions and attempts
The proposal was approved by the Champions in the email vote which ended
on October 30, 2010, with the following friendly amendments.
John - Friendly amendments
The proposal should be updated so that the changes are relative to IEEE 1800-2009.
I had difficulty distinguishing the blue color for new text from black.
Dave - Note
Please note which proposal was approved.
2330: Clarify that number_of_ticks argument to $past must be compile-time constant
The proposal was opposed by the Champions in the email vote which ended
on October 30, 2010.
John - Friendly amendment
I think that "must" should be "shall".
Shalom - Friendly amendment
Change "must be an elaboration time constant" to "shall be an elaboration
time constant expression".
Dave - Opposed
Use of the term "time constant" is particularly confusing in this context.
"Constant expression" is the proper term and represents a BNF non-terminal.
2387: Layout of 16.11 is inconsistent
The proposal was opposed by the Champions in the email vote which ended
on October 30, 2010.
Shalom - Opposed
Conflicts with 2476.
2552: Confusing comments regarding nexttime operator
The proposal was opposed by the Champions in the email vote which ended
on October 30, 2010.
Dave - Opposed
Fix 16.13.13 all at the same time.
Shalom - Opposed
The proposal does not address 16.13.13.
2557: Rules for passing automatic variables to sequence subroutines are not clear
The proposal was opposed by the Champions in the email vote which ended
on October 30, 2010.
Shalom - Opposed
I don't understand the reference to 6.24.
Dave - Friendly amendment
In the sentence added, should it be "nor" instead of "or"?
2722: Errors in Figures 16-14, 16-15, and 16-16
The proposal was approved by the Champions in the email vote which ended
on October 30, 2010, with the following friendly amendments.
Dave - Note
Please note which proposal was approved.
John - Friendly amendment
The new text in blue should not be underlined.
2804: Need to clarify rule (b) in 16.15.6 to allow inferred clock when expression appears in procedural assertion
The proposal was opposed by the Champions in the email vote which ended
on October 30, 2010.
Dave - Opposed
Address Shalom's bugnote.
Shalom - Note
My bugnote addressed the description in the Mantis database, but the
proposal is correct.
John - Opposed
I have some concerns about the wording and believe that the committee should
spend a bit more time on the technical substance of the modifications. One
concern regards the two-phase checking of condition c)1) before and after the
substitution of actual values for event arguments. It could be that a formal
event arguement appears as the entire event expression for the purposes of
c)1), thus apparently satisfying the condition, but there is some problem
satsifying c)1) after substituting the actual -- say the actual is
"ev1 or ev2", where ev1 and ev2 are themselves event variables. I'm not sure
what the proposal says to do in this situation. Another concern is the
meaning of the phrase "in such a way as to affect the state of the variables
assigned in the procedure, other than as a clocking event". Can this
condition be made simpler, such as "on the lefthand or righthand side of an
assignment in the procedure"? Finally, after some thought, I don't believe
that an event expression of the form "edge_identifier expression1 [iff
expression2]" can be a proper subexpression of an event expression of this
form. This condition is not being changed by the proposal and may have been
made unnecessary by changes to the event expression grammar. The committee
might consider eliminating it if it is no longer needed.
Francoise - Note
Not understanding the proposal.
2839: Contradictory statement of increment/decrement operators usage.
The proposal was opposed by the Champions in the email vote which ended
on October 30, 2010.
Dave - Opposed
"design variables" is not defined anywhere.
Should it be "sampled variables"?
2927: Precedence between sequence/property operator and normal expression operator
The proposal was opposed by the Champions in the email vote which ended
on October 30, 2010.
John - Friendly amendments
"Table 11.2" should be "Table 11-2".
Dave - Opposed
Was quorum achieved on this vote? Did not see voting results in the meeting
minutes for this issue
Shalom - Opposed
No technical objection, but Table 11-2 contains more than just logical and
arithmetical operators, and the sentence could be interpreted as making a
distinction.
2934: Precedence and associativity of case operator is not shown in the table
The proposal was opposed by the Champions in the email vote which ended
on October 30, 2010.
Francoise - Opposed
Could not find table 16.3 in the LRM, It would be nice to describe which
section it is to be found in.
3113: Add port_identifier to constant_primary BNF for sequences, properties and checkers
The proposal was opposed by the Champions in the email vote which ended
on October 30, 2010.
John - Friendly amendments
All of the footnotes should probably begin with the definite article "The".
Also "stays legal" should probably be just "is legal" because legality of a
construction is defined in terms of the result of the rewriting algorithm.
Shalom - Opposed
It took me a long time to figure out how this proposal answers the problem of
the Mantis. A typical person reading the LRM is likely not to understand the
reason that this footnote exists. I question that it really makes the BNF ok,
but at least there should be some discussion of this in the main text, and
an example illustrating the point. (Is there already?)
Francoise - Opposed
I do not understand the purpose of the note.
- Opens
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Nov 16 08:07:43 2010
This archive was generated by hypermail 2.1.8 : Tue Nov 16 2010 - 08:07:48 PST