I agree with Doron, ed > -----Original Message----- > From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On > Behalf Of Bustan, Doron > Sent: Thursday, November 22, 2007 9:09 AM > To: Johan Mårtensson > Cc: John Havlicek; sv-ac@eda.org > Subject: RE: [sv-ac] call to vote on 1757 > > Ed is the only one except us who already voted. > Since we are going to discuss it in a larger context in 1932, > I don't think it is a big dill. > > Doron > > >>-----Original Message----- > >>From: Johan M?rtensson [mailto:johan.martensson@jasper-da.com] > >>Sent: Thursday, November 22, 2007 3:21 PM > >>To: Bustan, Doron > >>Cc: John Havlicek; sv-ac@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, > >>> > >>> I have changed it to be the lowest precedence. > >>> I don't have a strong opinion about precedence. > >>> > >>> Doron > >>> > >>> >>-----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 |->, > >>> >>|=>, and if..else. I think users will find it intuitive that > >>everything > >>> >>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 > >>(Synopsys) > >>> >>> 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 > >>(Freescale > >>> >>- Chair) > >>> >>> v[xxxxxxxxxxxxxxxxxxxxxxxxxrxxxxxxxxxxxxx-xxx] > Dmitry Korchemny > >>(Intel > >>> >>- 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 = attended > >>> >>> - = missed > >>> >>> r = represented > >>> >>> . = not yet a member > >>> >>> v = valid voter (2 out of last 3 or > 3/4 overall) > >>> >>> n = not a valid voter > >>> >>> t = 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årtensson 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 > >>> > >>> 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. > >> > >> > >> > >>-- > >>------------------------------------------------------------ > >>Johan Mårtensson 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 > > 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 Thu Nov 22 06:27:23 2007
This archive was generated by hypermail 2.1.8 : Thu Nov 22 2007 - 06:27:44 PST