OK, I agree. Dmitry -----Original Message----- From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Behalf Of John Havlicek Sent: Thursday, November 22, 2007 6:47 PM To: Korchemny, Dmitry Cc: johan.martensson@jasper-da.com; Bustan, Doron; john.havlicek@freescale.com; sv-ac@server.eda.org Subject: Re: [sv-ac] call to vote on 1757 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. --------------------------------------------------------------------- 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 Sun Nov 25 01:24:44 2007
This archive was generated by hypermail 2.1.8 : Sun Nov 25 2007 - 01:25:33 PST