Hi Dmitry: Let the ballot and discussion run. People may change their votes. In the next meeting, whatever the outcome of the e-mail ballot, you can have discussion of the technical points and, if appropriate, call for a voice vote on the amended proposal. J.H. > X-ExtLoop1: 1 > X-IronPort-AV: E=Sophos;i="4.21,451,1188802800"; > d="scan'208";a="212678463" > X-MimeOLE: Produced By Microsoft Exchange V6.5 > Content-class: urn:content-classes:message > Date: Thu, 22 Nov 2007 15:23:45 +0200 > X-MS-Has-Attach: > X-MS-TNEF-Correlator: > Thread-Topic: [sv-ac] call to vote on 1757 > Thread-Index: AcgtCrD8oH4ImTh7SUCp/yVKRQ8AgQAABvmg > From: "Korchemny, Dmitry" <dmitry.korchemny@intel.com> > Cc: "John Havlicek" <john.havlicek@freescale.com>, <sv-ac@eda.org> > X-OriginalArrivalTime: 22 Nov 2007 13:23:55.0275 (UTC) FILETIME=[EE679DB0:01C82D0A] > > Hi John, > > What should we do? To call for a new voting or to continue the current one? > > Thanks, > Dmitry > > -----Original Message----- > From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Beh= > alf Of johan.martensson@jasper-da.com > Sent: Thursday, November 22, 2007 3:21 PM > To: Bustan, Doron > Cc: John Havlicek; sv-ac@server.eda.org > Subject: Re: [sv-ac] call to vote on 1757 > > Thanks, > > with that change I would vote yes. However I don't know if we can regard > that as a sufficiently minor change to just continue voting, or if we > need to call a new vote. Maybe someone has voted yes and liked the old > order better. > > Johan > > > > On Thu, Nov 22, 2007 at 02:45:02PM +0200, Bustan, Doron wrote: > > Johan, > >=20 > > I have changed it to be the lowest precedence. > > I don't have a strong opinion about precedence. > >=20 > > Doron > >=20 > > >>-----Original Message----- > > >>From: Johan M?rtensson [mailto:johan.martensson@jasper-da.com] > > >>Sent: Thursday, November 22, 2007 12:30 PM > > >>To: John Havlicek > > >>Cc: sv-ac@eda.org; Bustan, Doron > > >>Subject: Re: [sv-ac] call to vote on 1757 > > >> > > >>Hi, > > >> > > >>I vote no to AcceptRejecton1757.071122.pdf because I think we need to > > >>discuss the precedence of the abort operators relative to the others a > > >>little more. Following our discussion at Tuesday's meeting I see no > > >>reason why the abort operators should have higher precedence than |->, > > >>|=3D>, and if..else. I think users will find it intuitive that everythi= > ng > > >>to the right of the abort operator (with boolean) will be aborted. > > >> > > >>As far as I understand if the abort operators are given higher > > >>precedence than |-> then for example 'accept_on (c) a|->b' will be a > > >>syntax error because it will parse as '(accept_on (c) a)|->b' and > > >>'(accept_on (c) a)' is a property_expr which is disallowed at the LHS of > > >>|->. > > >> > > >>In PSL the abort operator has higher precedence than many of the > > >>property level (FL) operator, but (as I mentioned in our previous > > >>meeting), that makes sense because this operator is postfix. > > >> > > >>If the PSL abort operator would have had lower precedence that the |-> > > >>operator then '{a}|->{b} abort c' would have parsed as '({a}|->{b}) > > >>abort c' wheras the user probably has '{a}|->({b} abort c)' in mind. > > >>Similar considerations seem to be applicable in relation to PSL > > >>eventually!, until, always, never etc. which have lower precedence than > > >>abort in PSL. > > >> > > >>Furthermore I think the SVA abort operators can be safely placed beneath > > >>the 'if..else' operator since, I don't think the relative precedence of > > >>these operators has any impact on the parsing of either 'accept_on (a) > > >>if (b) then P else F' or 'if (b) then accept_on (a) P else accept_on (a) > > >>F' > > >> > > >>I also have some friendly amendments: > > >> > > >>16.12.3 > > >> > > >>I think 'semantics' is in the singular in this context. > > >>REPLACE > > >>The semantics of reject_on(expression_or_dits) property_expr are the > > >>same as not(accept_on(expression_or_dist) not(property_expr)). > > >>WITH > > >>The semantics of reject_on(expression_or_dits) property_expr is the > > >>same as not(accept_on(expression_or_dist) not(property_expr)). > > >> > > >>16.12.3 Abort properties > > >> > > >>The first and second example are duals but the explanations are slightly > > >>different. The first states "the truth of p1 is ignored in deciding the > > >>truth of p", and the second one says "then the second term is ignored in > > >>deciding the truth of p". I think both should be explained in the same > > >>way otherwise some may think there is some essential difference. > > >> > > >>For example (explanation to the first example.) > > >>REPLACE > > >>If a becomes true during the evaluation of p1, the truth of p1 is > > >>ignored in deciding the truth of p On the other hand, if b becomes true > > >>during the evaluation of p2 then p evaluates to false. > > >>WITH > > >>If a becomes true during the evaluation of p1, then the first term is > > >>ignored in deciding the truth of p On the other hand, if b becomes true > > >>during the evaluation of p2 then p evaluates to false. > > >> > > >>Best Regards, > > >> > > >>Johan > > >> > > >> > > >>On Tue, Nov 20, 2007 at 02:52:00PM -0600, John Havlicek wrote: > > >>> Hi Folks: > > >>> > > >>> This is the call to vote on the proposal for Mantis 1757. > > >>> > > >>> The document on Mantis is > > >>> > > >>> AcceptRejecton1757.071107.pdf > > >>> > > >>> Please vote if you are eligible. See the details below. > > >>> > > >>> J.H. > > >>> > > >>> ---------------------------------------------------------------------= > --- > > >>---------- > > >>> Ballot on Mantis 1757 > > >>> > > >>> - Called on 2007-11-20, final ballots due by 2007-11-26 T 23:59-08:00. > > >>> > > >>> v[xxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx-xx] Doron Bustan (Intel) > > >>> v[-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-x] Eduard Cerny (Synopsy= > s) > > >>> n[----------------x-xxx---------x-x-xxx-x---x] Surrendra Dudani > > >>(Synopsys) > > >>> v[xx-xxxxxx-xxxxxxxxx-xx-xxxxx-xxx-xxx-------] Yaniv Fais (Freescale) > > >>> t[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] John Havlicek (Freesc= > ale > > >>- Chair) > > >>> v[xxxxxxxxxxxxxxxxxxxxxxxxxrxxxxxxxxxxxxx-xxx] Dmitry Korchemny (Int= > el > > >>- Co-Chair) > > >>> v[xxxxxxxxx-xxx-x--xx--xxxxx----------xx-xxxx] Manisha Kulshrestha > > >>(Mentor Graphics) > > >>> n[------------------------xxxxx-------x-xx-x-] Jiang Long (Mentor > > >>Graphics) > > >>> n[---x------------x--xxx.....................] Joseph Lu (Altera) > > >>> v[xxxxxxxxxxxxx..............................] Johan Martensson > > >>(Jasper) > > >>> n[---------------------x--x-xx--xx-xxxxxxx-x-] Hillel Miller > > >>(Freescale) > > >>> v[xxxx-xxxxxxxxxxxxxxxxxxx-xxxxxxxx-xxxxxxxxx] Lisa Piper (Cadence) > > >>> v[xx-x-xx-xxxxxxx-x-xxxxx-x..................] Erik Seligman (Intel) > > >>> n[-x-x----x--------xxxx-----xxxx-xx----------] Tej Singh (Mentor > > >>Graphics) > > >>> v[-x-xxxxxx--xxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxx] Bassam Tabbara > > >>(Synopsys) > > >>> v[xxx-xxxxxxxxxxxxx-xxxxxxxxxx...............] Tom Thatcher (Sun > > >>Microsystems) > > >>> |------------------------------------------- attendance on 2007-11= > -20 > > >>> |--------------------------------------------- voting eligibility for > > >>this ballot > > >>> |---------------------------------------------- email ballots received > > >>> > > >>> Legend: > > >>> x =3D attended > > >>> - =3D missed > > >>> r =3D represented > > >>> . =3D not yet a member > > >>> v =3D valid voter (2 out of last 3 or 3/4 overall) > > >>> n =3D not a valid voter > > >>> t =3D chair eligible to vote only to make or break a = > tie > > >>> > > >>> > > >>> -- > > >>> This message has been scanned for viruses and > > >>> dangerous content by MailScanner, and is > > >>> believed to be clean. > > >> > > >>-- > > >>------------------------------------------------------------ > > >>Johan M=E5rtensson Office: +46 31 7451913 > > >>Jasper Design Automation Mobile: +46 703749681 > > >>Arvid Hedvalls backe 4 Fax: +46 31 7451939 > > >>411 33 Gothenburg, Sweden Skype ID: johanmartensson > > >>------------------------------------------------------------ > > --------------------------------------------------------------------- > > Intel Israel (74) Limited > >=20 > > 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. > > > > --=20 > ------------------------------------------------------------ > Johan M=E5rtensson Office: +46 31 7451913 > Jasper Design Automation Mobile: +46 703749681=20 > Arvid Hedvalls backe 4 Fax: +46 31 7451939 > 411 33 Gothenburg, Sweden Skype ID: johanmartensson > ------------------------------------------------------------ > > --=20 > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > --------------------------------------------------------------------- > 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 Thu Nov 22 08:47:13 2007
This archive was generated by hypermail 2.1.8 : Thu Nov 22 2007 - 08:47:52 PST