Hello Dmitry,
Given the DST time change, it is now 13.30 hours difference bet'n
India & US (PST). That becomes 22.00 to 23.30 for India late night for
this call. I understand it is hard to change as many timezones are
involved, but still wanted to run through the team to see if this
could be revisited. 1 hour earlier would be good or evening PST times
may suit.
Please note that as of now I am mostly an observer and not an active
contributor so if there are urgent pending things in the committee,
feel free to continue with no change, but do consider this request if
feasible.
Thanks
Srini
www.cvcblr.com
On Tue, Nov 30, 2010 at 6:31 PM, Korchemny, Dmitry
<dmitry.korchemny@intel.com> wrote:
> Date: 2010-11-30
>
> 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=5745158
>
>
>
> Agenda:
>
> -------
>
> - Reminder of IEEE patent policy.
>
> See: http://standards.ieee.org/board/pat/pat-slideset.ppt
>
>
>
> - Minutes approval
>
>
>
> - Email ballot results
>
> 2552: Confusing comments regarding nexttime operator
>
> The issue passed: 10y/0n/0a
>
>
>
> - New issues
>
> 3295: need a way to control only asserts/covers/assume directives
>
>
>
> - Issue resolution/discussion
>
> Addressing champions’ feedback.
>
>
>
> 2330: Clarify that number_of_ticks argument to $past must be compile-time
> constant
>
> · John volunteered to update the proposal.
>
>
>
> 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
>
> · Erik to make proposals consistent.
>
>
>
> The proposal was opposed by the Champions in the email vote which ended
> on October 30, 2010.
>
> Shalom - Opposed
> Conflicts with 2476.
>
>
>
> 2557: Rules for passing automatic variables to sequence subroutines are not
> clear
>
> · Erik to modify the proposal and to remove the reference.
>
>
>
> 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"?
>
>
>
> 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.
>
>
>
> 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.
>
>
>
>
>
> - Enhancement progress update
>
> 3034 - Allow procedural control statements is checkers
>
> Arguments for system functions
>
>
>
>
>
> - 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.
-- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Nov 30 06:47:33 2010
This archive was generated by hypermail 2.1.8 : Tue Nov 30 2010 - 06:47:44 PST