Re: [sv-ac] RE: call to vote on 2173

From: John Havlicek <john.havlicek_at_.....>
Date: Mon Feb 18 2008 - 09:16:53 PST
Hi Yaniv:

I think we need to converge on what syntax we want and then 
see how to accommodate the VPI.  From my perspective, there
could be a resonable tradeoff between syntax improvement and 
VPI backward compatibility.

J.H.

> Content-class: urn:content-classes:message
> X-MimeOLE: Produced By Microsoft Exchange V6.5
> X-OriginalArrivalTime: 18 Feb 2008 16:39:23.0250 (UTC) FILETIME=[D12C9520:01C8724C]
> Date: Mon, 18 Feb 2008 09:39:20 -0700
> X-MS-Has-Attach: 
> X-MS-TNEF-Correlator: 
> Thread-Topic: [sv-ac] RE: call to vote on 2173
> Thread-Index: AchuNGFgmmUEFXhSRy6dB1DW1FANJQD+NjhgAAE6+gAABCPMAAAA2/swAADbcXAAAEJ2IA==
> From: "Fais Yaniv" <yaniv.fais@freescale.com>
> Cc: "Lisa Piper" <piper@cadence.com>,
> 	"Korchemny, Dmitry" <dmitry.korchemny@intel.com>
> 
> This is a multi-part message in MIME format.
> 
> ------_=_NextPart_001_01C8724C.D19F0600
> Content-Type: text/plain;
> 	charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> 
> Hi Bassam,
> =20
> Sorry for not being specific enough and also for being ignorant on VPI -
> I meant that the change is backwards compatible in terms of the syntax
> but I definitely agree it isn't backwards compatible in terms of the
> VPI.=20
> =20
> Therefore I shall put back the the if-else inside the property expr in
> VPI and remove property stmt from the VPI - I will try therefore to
> incorporate the case into the VPI  diagram of property expr (such as in
> 36.62) and see how it goes.
> =20
> =20
> Thanks,
> Yaniv
> =20
> 
> ________________________________
> 
> From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com]=20
> Sent: Monday, February 18, 2008 18:22
> To: Fais Yaniv; Bassam Tabbara; Havlicek John; sv-ac@eda.org
> Cc: Lisa Piper; Korchemny, Dmitry
> Subject: RE: [sv-ac] RE: call to vote on 2173
> 
> 
> Hi Yaniv,
> =20
> I did see your reply, and I don't understand the 2nd bullet -- it occurs
> to me just now that you seem to be mixing the BNF and the VPI, they are
> independent (sometimes BNF is used as a starting point for VPI model's
> inspiration yes but they are certainly not 1-1) ... you can surely make
> the change to BNF (because of ";" (?) I have to look that over to
> understand) and keep VPI as is (+ add operator). Again "property_expr"
> is just a modeling construct actually different from the "property_expr"
> construct in BNF.
> =20
> As to the 1st this is *not* backward compatible as far as VPI -- you now
> have the extra property statement wrapper.
> =20
> Thx.
> -Bassam.
> =20
> 
> ________________________________
> 
> From: Fais Yaniv [mailto:yaniv.fais@freescale.com]=20
> Sent: Monday, February 18, 2008 8:14 AM
> To: Bassam Tabbara; Havlicek John; sv-ac@eda.org
> Cc: Lisa Piper; Korchemny, Dmitry
> Subject: RE: [sv-ac] RE: call to vote on 2173
> 
> 
> Hi Bassam,
> =20
> have you seen my reply to Lisa ? (it also took time to show in the
> reflector)
> =20
> I appended it to this mail so please comment if there is anything you
> disagree on so we can converge for the next vote.
> =20
> =20
> I want to highlight this again:
>    - the if-else is backwards compatible and it was moved to the
> property statement layer since it seems more adequate there (it is a
> statement also in procedural code).
>    - adding the operator to the property_expr would make this construct
> use irregular in SV (because of the semicolon after endcase) and we were
> trying to avoid just that.
> =20
> Thanks,
> Yaniv
> =20
> 
> 
> ________________________________
> 
> From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com]=20
> Sent: Monday, February 18, 2008 17:36
> To: Fais Yaniv; Korchemny, Dmitry; Havlicek John; sv-ac@eda.org
> Cc: Lisa Piper
> Subject: RE: [sv-ac] RE: call to vote on 2173
> 
> 
> Hi Yaniv/all,
> =20
> Seems reflector swallowed my earlier vote on this. I voted no because of
> the VPI issues -- I did not see the note on page 1 at the time but
> regardless I agree with Lisa -- I don't understand why you have
> "property stmt" and the backward incompatible changes that affect
> if-else. I think just adding operand to property_expr should do -- I
> don't accept the reasoning for "changing case/endcase", this construct
> is part of SV and should not be changed in any way here.
> =20
> ** It might be better to just split proposal in this case. I really see
> no reason for the radical changes here for something as trivial as a new
> operator, please split to permit a yes vote on the content portion.
> =20
> Thx.
> -Bassam.
> =20
> 
> ________________________________
> 
> From: owner-sv-ac@eda.org [mailto:owner-sv-ac@eda.org] On Behalf Of Fais
> Yaniv
> Sent: Monday, February 18, 2008 6:09 AM
> To: Korchemny, Dmitry; Havlicek John; sv-ac@eda.org
> Subject: [sv-ac] RE: call to vote on 2173
> 
> 
> 
> Hi Dmitry,
> 
> please see my comments below.
> 
> Yaniv
> 
> -----Original Message-----
> From: Korchemny, Dmitry [mailto:dmitry.korchemny@intel.com]
> Sent: Monday, February 18, 2008 15:10
> To: Havlicek John; sv-ac@eda.org
> Cc: Bustan, Doron; eduard.cerny@synopsys.com; Fais Yaniv;
> Manisha_Kulshrestha@mentor.com; johan.martensson@jasper-da.com;
> piper@cadence.com; Seligman, Erik; bassam.tabbara@synopsys.com;
> thomas.thatcher@sun.com
> Subject: RE: call to vote on 2173
> 
> Hi John, Yaniv,
> 
> I have the following questions/comments:
> 
> * Page 3, bottom. The statement "The case expression given in
> parentheses shall be evaluated exactly once and before any of the case
> item statements."
> 
> is not clear to me. As far as I understand al the expressions in the
> case statement should be sampled (unless they are continuous checker
> variables). I think that this statement has to be deleted.
> 
> * I suggest rewriting the whole paragraph, describing the case
> statement, it should use more intuitive language.
> 
> [Yaniv Fais] actually this paragraph was almost copy pasted from the
> procedural case statement (see 12.5) since I found it defines exactly
> how this evaluates in a nonambiguous way , I agree however that the
> sentence you've mentioned is irrelevant since it is meaningful only when
> the expressions are allowed to have side effects so I shall remove it.
> 
> * Fix fonts in h) and in 16.5.1 on page 4.
> 
> [Yaniv Fais] I made "(b!=3D=3Db1 && b!=3D=3Db2)" Italic in "h)", and =
> "b1:q1
> b2:q2" Times-New Roman /Italic/10 in 16.5.1
> 
> * Page 4, 36.45
> 
> VPI looks incomplete. property_stmt is not explained.
> 
> [Yaniv Fais] The VPI diagram for property statement is missing, it
> should be done hopefully with collaboration from SV-CC (This is
> mentioned on page 1).
> 
> Dmitry
> 
> -----Original Message-----
> From: John Havlicek [mailto:john.havlicek@freescale.com]
> Sent: Wednesday, February 13, 2008 1:32 PM
> To: sv-ac@eda.org
> Cc: Bustan, Doron; eduard.cerny@synopsys.com; yaniv.fais@freescale.com;
> john.havlicek@freescale.com; Korchemny, Dmitry;
> Manisha_Kulshrestha@mentor.com; johan.martensson@jasper-da.com;
> piper@cadence.com; Seligman, Erik; bassam.tabbara@synopsys.com;
> thomas.thatcher@sun.com
> Subject: call to vote on 2173
> 
> This is the call to vote on 2173.
> The document on Mantis is 2173_prop_case_080212_yf.pdf.
> 
> ------------------------------------------------------------------------
> ----------
> Ballot on Mantis 2173
> 
> - Called on 2008-02-13, final ballots due by 2008-02-18 T 23:59-08:00.
> - Please ensure that Dmitry Korchemny receives your ballot.
> 
>  v[-xxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx-xx] Doron Bustan
> (Intel)
>  v[xxxxxxxxx--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx-x] Eduard Cerny
> (Synopsys)   =20
>  n[--------------------------x-xxx---------x-x-xxx-x---x] Surrendra
> Dudani (Synopsys)
> v[xx-xxxxxxxxx-xxxxxx-xxxxxxxxx-xx-xxxxx-xxx-xxx-------] Yaniv Fais
> (Freescale)
>  t[xxxxxxxx--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx] John Havlicek
> (Freescale - Chair)
> v[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxrxxxxxxxxxxxxx-xxx] Dmitry
> Korchemny (Intel - Co-Chair)
> v[xxxxxxxxx-xxxxxxxxx-xxx-x--xx--xxxxx----------xx-xxxx] Manisha
> Kulshrestha (Mentor Graphics)
> n[-x-x-------------------------------------------------] Ah-Lam Lee
> (Qualcomm)
>  n[----------------------------------xxxxx-------x-xx-x-] Jiang Long
> (Mentor Graphics)
> n[-------------x------------x--xxx.....................] Joseph Lu
> (Altera)
>  n[-x--xxxxxxxxxxxxxxxxxxx..............................] Johan
> Martensson (Jasper)
> n[-------------------------------x--x-xx--xx-xxxxxxx-x-] Hillel Miller
> (Freescale)
>  v[xxxxxxxxx-xxxx-xxxxxxxxxxxxxxxxxxx-xxxxxxxx-xxxxxxxxx] Lisa Piper
> (Cadence)
>  v[xxxxxxxxxx-x-x-xx-xxxxxxx-x-xxxxx-x..................] Erik Seligman
> (Intel)
>  n[-----------x-x----x--------xxxx-----xxxx-xx----------] Tej Singh
> (Mentor Graphics)
> v[xxx-xxxxxx-x-xxxxxx--xxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxx] Bassam Tabbara
> (Synopsys)
>  v[xxxxxxxxxxxxx-xxxxxxxxxxxxx-xxxxxxxxxx...............] Tom Thatcher
> (Sun Microsystems)
>    |----------------------------------------------------- attendance on
> 2008-02-12
>  |------------------------------------------------------- voting
> eligibility for this ballot
> |-------------------------------------------------------- e-mail votes
> 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
> ---------------------------------------------------------------------
> 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.
> 
> 
> 
> 
> --=20
> This message has been scanned for viruses and=20
> dangerous content by MailScanner <http://www.mailscanner.info/> , and is
> 
> believed to be clean.=20
> 
> =20
> Append of earlier mail addressing comments from Lisa:
>  =20
> 
> Hi Lisa,
> 
> please see my comments below.
> 
> Yaniv
> 
> -----Original Message-----
> From: Lisa Piper [mailto:piper@cadence.com]
> Sent: Saturday, February 16, 2008 01:30
> To: Havlicek John; sv-ac@eda.org
> Cc: doron.bustan@intel.com; eduard.cerny@synopsys.com; Fais Yaniv;
> dmitry.korchemny@intel.com; Manisha_Kulshrestha@mentor.com;
> johan.martensson@jasper-da.com; erik.seligman@intel.com;
> bassam.tabbara@synopsys.com; thomas.thatcher@sun.com
> Subject: RE: call to vote on 2173
> 
> Why does this proposal add this to property but not to sequences. The
> one example that is provided seems to be more appropriate for a
> sequence.
> 
> 
> 
> [Yaniv Fais] Although Mantis 2173 asks to add the case construct to
> sequences and properties John and I decided at this late stage to add
> the "case" construct to properties only (which maybe extended to
> sequences later) - this is because properties already have a higher
> level statement like "if...else" whereas sequences only have sequence
> expressions with the sequence operators
> 
> In the VPI diagrams (36.45 Property specification) the blue "stmt"
> should be "statement".=20
> 
> [Yaniv Fais] I have notices throughout clause 36 (VPI diagrams) "stmt"
> is used consistently as an abbreviation for statement whereas "expr" for
> expression (see 36.51 for example) therefore I thought "property
> statement" should be "property stmt" much like there is "atomic stmt" or
> "foreach stmt".
> 
> 
> Why was property statement created instead of just adding this to
> property_expr.  What was lost by moving the if-else out from
> property_expr? I feel like I am missing something.
> 
> 
> [Yaniv Fais] property statement was created in order to avoid the
> addition of extra semicolons in uncommon places - for example if "case"
> was added inside property_expr then it would be required to write for
> example:
> 
> property p;
> 
> s |=3D>=20
> 
>   case (wait)
> 
>     1:...
> 
>   endcase ;
> 
> endproperty
> 
> notice here there is an extra semicolon after the endcase - this is
> uncommon in the language and we wanted to avoid it.
> 
> =20
> 
> regarding moving if..else out from property_expr to property statement :
> I think this is backward compatible since property statement is also
> "property_expr ; " therefore the same syntax which was allowed before is
> also allowed now - by making this change however new syntax is added -
> for example:
> 
> if (expr1)
> 
>   a |=3D> b;
> 
> else
> 
>   a && b;
> 
> =20
> 
> In the past this was illegal because of the semicolons but now the
> semicolons are optional , by this proposal however it would be possible
> to put extra semicolons after every property_expr so also "if (e1) q1;;
> else q2" is legal (this is written in the comments addressed in the
> objective part of the proposal).
> 
> 
> Lisa
> 
> 
> 
> 
> ------_=_NextPart_001_01C8724C.D19F0600
> Content-Type: text/html;
> 	charset="us-ascii"
> Content-Transfer-Encoding: quoted-printable
> 
> <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
> <HTML><HEAD><TITLE></TITLE>
> <META http-equiv=3DContent-Type content=3D"text/html; =
> charset=3Dus-ascii">
> <META content=3D"MSHTML 6.00.6000.16587" name=3DGENERATOR></HEAD>
> <BODY>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D533362316-18022008><FONT =
> face=3DArial=20
> color=3D#0000ff>Hi Bassam,</FONT></SPAN></DIV>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D533362316-18022008><FONT =
> face=3DArial=20
> color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D533362316-18022008><FONT =
> face=3DArial=20
> color=3D#0000ff>Sorry for not being specific enough and also for being =
> ignorant on=20
> VPI&nbsp;- I meant that the change is backwards compatible in terms of =
> the=20
> syntax but I definitely agree it isn't backwards compatible in terms of =
> the=20
> VPI.&nbsp;</FONT></SPAN></DIV>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D533362316-18022008><FONT =
> face=3DArial=20
> color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D533362316-18022008><FONT =
> face=3DArial=20
> color=3D#0000ff>Therefore I shall put back the the if-else inside the =
> property=20
> expr in VPI and remove property stmt from the VPI - I will try therefore =
> to=20
> incorporate the case into the VPI&nbsp; diagram of property expr (such =
> as in=20
> 36.62) and see how it goes.</FONT></SPAN></DIV>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D533362316-18022008><FONT =
> face=3DArial=20
> color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D533362316-18022008><FONT =
> face=3DArial=20
> color=3D#0000ff></FONT></SPAN>&nbsp;</DIV>
> <DIV dir=3Dltr align=3Dleft><SPAN class=3D533362316-18022008><FONT =
> face=3DArial=20
> color=3D#0000ff>Thanks,</FONT></SPAN></DIV>
> <DIV><SPAN class=3D533362316-18022008></SPAN><FONT face=3DArial =
> color=3D#0000ff><SPAN=20
> class=3D533362316-18022008>Yaniv</SPAN></FONT></DIV>
> <DIV><FONT face=3DArial color=3D#0000ff><SPAN=20
> class=3D533362316-18022008></SPAN></FONT>&nbsp;</DIV>
> <DIV dir=3Dltr align=3Dleft><BR></DIV>
> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
> <HR tabIndex=3D-1>
> <FONT face=3DTahoma size=3D2><B>From:</B> Bassam Tabbara=20
> [mailto:Bassam.Tabbara@synopsys.com] <BR><B>Sent:</B> Monday, February =
> 18, 2008=20
> 18:22<BR><B>To:</B> Fais Yaniv; Bassam Tabbara; Havlicek John;=20
> sv-ac@eda.org<BR><B>Cc:</B> Lisa Piper; Korchemny, =
> Dmitry<BR><B>Subject:</B> RE:=20
> [sv-ac] RE: call to vote on 2173<BR></FONT><BR></DIV>
> <DIV></DIV>
> <DIV><SPAN class=3D559101616-18022008><FONT face=3DArial color=3D#0000ff =
> size=3D2>Hi=20
> Yaniv,</FONT></SPAN></DIV>
> <DIV><SPAN class=3D559101616-18022008><FONT face=3DArial color=3D#0000ff =
> 
> size=3D2></FONT></SPAN>&nbsp;</DIV>
> <DIV><SPAN class=3D559101616-18022008><FONT face=3DArial color=3D#0000ff =
> size=3D2>I did=20
> see your reply, and I don't understand the 2nd bullet -- it occurs to me =
> just=20
> now that you seem to be mixing the BNF and the VPI, they are independent =
> 
> (sometimes BNF is used as a starting point for VPI model's inspiration =
> yes but=20
> they are certainly not 1-1) ... you can surely make the change to=20
> BNF&nbsp;(because of ";" (?) I have to look that over to understand) and =
> keep=20
> VPI as is (+ add operator). Again "property_expr" is just a modeling =
> construct=20
> actually different from the "property_expr" construct in=20
> BNF.</FONT></SPAN></DIV>
> <DIV><SPAN class=3D559101616-18022008><FONT face=3DArial color=3D#0000ff =
> 
> size=3D2></FONT></SPAN>&nbsp;</DIV>
> <DIV><SPAN class=3D559101616-18022008><FONT face=3DArial color=3D#0000ff =
> size=3D2>As to=20
> the 1st this is *not* backward compatible as far as VPI -- you now have =
> the=20
> extra property statement wrapper.</FONT></SPAN></DIV>
> <DIV>&nbsp;</DIV>
> <DIV align=3Dleft><FONT face=3DArial size=3D2>Thx.</FONT></DIV>
> <DIV align=3Dleft><FONT face=3DArial size=3D2>-Bassam.</FONT></DIV>
> <DIV>&nbsp;</DIV><BR>
> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
> <HR tabIndex=3D-1>
> <FONT face=3DTahoma size=3D2><B>From:</B> Fais Yaniv=20
> [mailto:yaniv.fais@freescale.com] <BR><B>Sent:</B> Monday, February 18, =
> 2008=20
> 8:14 AM<BR><B>To:</B> Bassam Tabbara; Havlicek John; =
> sv-ac@eda.org<BR><B>Cc:</B>=20
> Lisa Piper; Korchemny, Dmitry<BR><B>Subject:</B> RE: [sv-ac] RE: call to =
> vote on=20
> 2173<BR></FONT><BR></DIV>
> <DIV></DIV>
> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff><SPAN=20
> class=3D877375115-18022008>Hi Bassam,</SPAN></FONT></DIV>
> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff><SPAN=20
> class=3D877375115-18022008></SPAN></FONT>&nbsp;</DIV>
> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff><SPAN=20
> class=3D877375115-18022008>have you seen my reply to Lisa ?=20
> (it&nbsp;also&nbsp;took time to show in the =
> reflector)</SPAN></FONT></DIV>
> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff><SPAN=20
> class=3D877375115-18022008></SPAN></FONT>&nbsp;</DIV>
> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff><SPAN=20
> class=3D877375115-18022008>I appended it to this mail so please comment =
> if there=20
> is anything you disagree on so we can converge for the next=20
> vote.</SPAN></FONT></DIV>
> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff><SPAN=20
> class=3D877375115-18022008></SPAN></FONT>&nbsp;</DIV>
> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff><SPAN=20
> class=3D877375115-18022008></SPAN></FONT>&nbsp;</DIV>
> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff><SPAN=20
> class=3D877375115-18022008>I want to highlight this =
> again:</SPAN></FONT></DIV>
> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff><SPAN=20
> class=3D877375115-18022008>&nbsp; &nbsp;- the if-else is backwards =
> compatible and=20
> it was moved to the property statement layer since it seems more =
> adequate there=20
> (it is a statement also in procedural code).</SPAN></FONT></DIV>
> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff><SPAN=20
> class=3D877375115-18022008>&nbsp;&nbsp; - adding the operator to the =
> property_expr=20
> would make this construct use irregular in SV (because of the semicolon =
> after=20
> endcase) and we were trying to avoid just that.</SPAN></FONT></DIV>
> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff><SPAN=20
> class=3D877375115-18022008></SPAN></FONT>&nbsp;</DIV>
> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff><SPAN=20
> class=3D877375115-18022008>Thanks,</SPAN></FONT></DIV>
> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff><SPAN=20
> class=3D877375115-18022008>Yaniv</SPAN></FONT></DIV>
> <DIV dir=3Dltr align=3Dleft><FONT face=3DArial color=3D#0000ff><SPAN=20
> class=3D877375115-18022008></SPAN></FONT>&nbsp;</DIV><FONT face=3DArial=20
> color=3D#0000ff></FONT><FONT face=3DArial color=3D#0000ff></FONT><BR>
> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
> <HR tabIndex=3D-1>
> <FONT face=3DTahoma size=3D2><B>From:</B> Bassam Tabbara=20
> [mailto:Bassam.Tabbara@synopsys.com] <BR><B>Sent:</B> Monday, February =
> 18, 2008=20
> 17:36<BR><B>To:</B> Fais Yaniv; Korchemny, Dmitry; Havlicek John;=20
> sv-ac@eda.org<BR><B>Cc:</B> Lisa Piper<BR><B>Subject:</B> RE: [sv-ac] =
> RE: call=20
> to vote on 2173<BR></FONT><BR></DIV>
> <DIV></DIV>
> <DIV><SPAN class=3D647012715-18022008><FONT face=3DArial color=3D#0000ff =
> size=3D2>Hi=20
> Yaniv/all,</FONT></SPAN></DIV>
> <DIV><SPAN class=3D647012715-18022008><FONT face=3DArial color=3D#0000ff =
> 
> size=3D2></FONT></SPAN>&nbsp;</DIV>
> <DIV><SPAN class=3D647012715-18022008><FONT face=3DArial color=3D#0000ff =
> size=3D2>Seems=20
> reflector swallowed my earlier vote on this. I voted no because of the =
> VPI=20
> issues -- I did not see the note on page 1 at the time but regardless I =
> agree=20
> with Lisa -- I don't understand why you have "property stmt" and the =
> backward=20
> incompatible changes that affect if-else.&nbsp;</FONT></SPAN><SPAN=20
> class=3D647012715-18022008><FONT face=3DArial color=3D#0000ff size=3D2>I =
> think just=20
> adding operand to property_expr should do -- I don't accept the =
> reasoning for=20
> "changing case/endcase", this construct is part of SV and should not be =
> changed=20
> in any way here.</FONT></SPAN></DIV>
> <DIV><SPAN class=3D647012715-18022008><FONT face=3DArial color=3D#0000ff =
> 
> size=3D2></FONT></SPAN>&nbsp;</DIV>
> <DIV><SPAN class=3D647012715-18022008><FONT face=3DArial color=3D#0000ff =
> 
> size=3D2>**&nbsp;It&nbsp;might be better to just split proposal in this =
> case. I=20
> really see no reason for the radical changes here for something as =
> trivial as a=20
> new operator, please split&nbsp;to permit a yes vote&nbsp;on the content =
> 
> portion.</FONT></SPAN></DIV>
> <DIV>&nbsp;</DIV>
> <DIV align=3Dleft><FONT face=3DArial size=3D2>Thx.</FONT></DIV>
> <DIV align=3Dleft><FONT face=3DArial size=3D2>-Bassam.</FONT></DIV>
> <DIV>&nbsp;</DIV><BR>
> <DIV class=3DOutlookMessageHeader lang=3Den-us dir=3Dltr align=3Dleft>
> <HR tabIndex=3D-1>
> <FONT face=3DTahoma size=3D2><B>From:</B> owner-sv-ac@eda.org=20
> [mailto:owner-sv-ac@eda.org] <B>On Behalf Of </B>Fais =
> Yaniv<BR><B>Sent:</B>=20
> Monday, February 18, 2008 6:09 AM<BR><B>To:</B> Korchemny, Dmitry; =
> Havlicek=20
> John; sv-ac@eda.org<BR><B>Subject:</B> [sv-ac] RE: call to vote on=20
> 2173<BR></FONT><BR></DIV>
> <DIV></DIV><!-- Converted from text/plain format -->
> <P><FONT size=3D2>Hi Dmitry,<BR><BR>please see my comments=20
> below.<BR><BR>Yaniv<BR><BR>-----Original Message-----<BR>From: =
> Korchemny, Dmitry=20
> [<A=20
> href=3D"mailto:dmitry.korchemny@intel.com">mailto:dmitry.korchemny@intel.=
> com</A>]<BR>Sent:=20
> Monday, February 18, 2008 15:10<BR>To: Havlicek John; =
> sv-ac@eda.org<BR>Cc:=20
> Bustan, Doron; eduard.cerny@synopsys.com; Fais Yaniv;=20
> Manisha_Kulshrestha@mentor.com; johan.martensson@jasper-da.com;=20
> piper@cadence.com; Seligman, Erik; bassam.tabbara@synopsys.com;=20
> thomas.thatcher@sun.com<BR>Subject: RE: call to vote on 2173<BR><BR>Hi =
> John,=20
> Yaniv,<BR><BR>I have the following questions/comments:<BR><BR>* Page 3, =
> bottom.=20
> The statement "The case expression given in parentheses shall be =
> evaluated=20
> exactly once and before any of the case item statements."<BR><BR>is not =
> clear to=20
> me. As far as I understand al the expressions in the case statement =
> should be=20
> sampled (unless they are continuous checker variables). I think that =
> this=20
> statement has to be deleted.<BR><BR>* I suggest rewriting the whole =
> paragraph,=20
> describing the case statement, it should use more intuitive=20
> language.<BR><BR><FONT color=3D#0000ff>[Yaniv Fais] actually this =
> paragraph was=20
> almost copy pasted from the procedural case statement (see 12.5) since I =
> found=20
> it defines exactly how this evaluates in a nonambiguous way , I agree =
> however=20
> that the sentence you've mentioned is irrelevant since it is meaningful =
> only=20
> when the expressions are allowed to have side effects so I shall remove=20
> it.</FONT><BR><BR>* Fix fonts in h) and in 16.5.1 on page 4.</FONT></P>
> <P><FONT size=3D2><SPAN=20
> style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Times New Roman'; =
> mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
> mso-fareast-language: EN-US; mso-bidi-language: HE">[Yaniv=20
> Fais] I made "<EM>(b!=3D=3Db</EM></SPAN><EM><SPAN=20
> style=3D"FONT-SIZE: 8pt; COLOR: blue; FONT-FAMILY: 'Times New Roman'; =
> mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
> mso-fareast-language: EN-US; mso-bidi-language: HE">1</SPAN><SPAN=20
> style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Times New Roman'; =
> mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
> mso-fareast-language: EN-US; mso-bidi-language: HE">=20
> &amp;&amp; b!=3D=3Db</SPAN><SPAN=20
> style=3D"FONT-SIZE: 8pt; COLOR: blue; FONT-FAMILY: 'Times New Roman'; =
> mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
> mso-fareast-language: EN-US; mso-bidi-language: HE">2)"=20
> Italic in "h)", <FONT size=3D2>and "</FONT><SPAN=20
> style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Times New Roman'; =
> mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
> mso-fareast-language: EN-US; mso-bidi-language: HE">b</SPAN><SPAN=20
> style=3D"FONT-SIZE: 8pt; COLOR: blue; FONT-FAMILY: 'Times New Roman'; =
> mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
> mso-fareast-language: EN-US; mso-bidi-language: HE">1</SPAN><SPAN=20
> style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Times New Roman'; =
> mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
> mso-fareast-language: EN-US; mso-bidi-language: HE">:q</SPAN><SPAN=20
> style=3D"FONT-SIZE: 8pt; COLOR: blue; FONT-FAMILY: 'Times New Roman'; =
> mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
> mso-fareast-language: EN-US; mso-bidi-language: HE">1</SPAN><SPAN=20
> style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Times New Roman'; =
> mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
> mso-fareast-language: EN-US; mso-bidi-language: HE">=20
> b</SPAN><SPAN=20
> style=3D"FONT-SIZE: 8pt; COLOR: blue; FONT-FAMILY: 'Times New Roman'; =
> mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
> mso-fareast-language: EN-US; mso-bidi-language: HE">2</SPAN><SPAN=20
> style=3D"FONT-SIZE: 10pt; COLOR: blue; FONT-FAMILY: 'Times New Roman'; =
> mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
> mso-fareast-language: EN-US; mso-bidi-language: HE">:q</SPAN><SPAN=20
> style=3D"FONT-SIZE: 8pt; COLOR: blue; FONT-FAMILY: 'Times New Roman'; =
> mso-fareast-font-family: 'Times New Roman'; mso-ansi-language: EN-US; =
> mso-fareast-language: EN-US; mso-bidi-language: HE">2"=20
> Times-New Roman /Italic/10 in 16.5.1</SPAN></SPAN></EM><BR><BR>* Page 4, =
> 
> 36.45<BR><BR>VPI looks incomplete. property_stmt is not =
> explained.</FONT></P>
> <P><FONT size=3D2><FONT color=3D#0000ff>[Yaniv Fais] The VPI diagram for =
> property=20
> statement is missing, it should be done hopefully with collaboration =
> from SV-CC=20
> (This is&nbsp;mentioned on page =
> 1).</FONT><BR><BR>Dmitry<BR><BR>-----Original=20
> Message-----<BR>From: John Havlicek [<A=20
> href=3D"mailto:john.havlicek@freescale.com">mailto:john.havlicek@freescal=
> e.com</A>]<BR>Sent:=20
> Wednesday, February 13, 2008 1:32 PM<BR>To: sv-ac@eda.org<BR>Cc: Bustan, =
> Doron;=20
> eduard.cerny@synopsys.com; yaniv.fais@freescale.com;=20
> john.havlicek@freescale.com; Korchemny, Dmitry; =
> Manisha_Kulshrestha@mentor.com;=20
> johan.martensson@jasper-da.com; piper@cadence.com; Seligman, Erik;=20
> bassam.tabbara@synopsys.com; thomas.thatcher@sun.com<BR>Subject: call to =
> vote on=20
> 2173<BR><BR>This is the call to vote on 2173.<BR>The document on Mantis =
> is=20
> 2173_prop_case_080212_yf.pdf.<BR><BR>------------------------------------=
> ------------------------------------<BR>----------<BR>Ballot=20
> on Mantis 2173<BR><BR>- Called on 2008-02-13, final ballots due by =
> 2008-02-18 T=20
> 23:59-08:00.<BR>- Please ensure that Dmitry Korchemny receives your=20
> ballot.<BR><BR>&nbsp;v[-xxxxxxxxxxxxxxxxxxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxxx=
> -xx]=20
> Doron=20
> Bustan<BR>(Intel)<BR>&nbsp;v[xxxxxxxxx--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
> xxxxxxx-x]=20
> Eduard=20
> Cerny<BR>(Synopsys)&nbsp;&nbsp;&nbsp;&nbsp;<BR>&nbsp;n[------------------=
> --------x-xxx---------x-x-xxx-x---x]=20
> Surrendra Dudani (Synopsys)&nbsp;=20
> v[xx-xxxxxxxxx-xxxxxx-xxxxxxxxx-xx-xxxxx-xxx-xxx-------] Yaniv=20
> Fais<BR>(Freescale)<BR>&nbsp;t[xxxxxxxx--xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx=
> xxxxxxxxxxx]=20
> John Havlicek (Freescale - Chair)&nbsp;=20
> v[xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxrxxxxxxxxxxxxx-xxx] Dmitry =
> Korchemny (Intel=20
> - Co-Chair)&nbsp; =
> v[xxxxxxxxx-xxxxxxxxx-xxx-x--xx--xxxxx----------xx-xxxx]=20
> Manisha Kulshrestha (Mentor Graphics)&nbsp;=20
> n[-x-x-------------------------------------------------] Ah-Lam=20
> Lee<BR>(Qualcomm)<BR>&nbsp;n[----------------------------------xxxxx-----=
> --x-xx-x-]=20
> Jiang Long (Mentor Graphics)&nbsp;=20
> n[-------------x------------x--xxx.....................] Joseph=20
> Lu<BR>(Altera)<BR>&nbsp;n[-x--xxxxxxxxxxxxxxxxxxx........................=
> ......]=20
> Johan Martensson (Jasper)&nbsp;=20
> n[-------------------------------x--x-xx--xx-xxxxxxx-x-] Hillel=20
> Miller<BR>(Freescale)<BR>&nbsp;v[xxxxxxxxx-xxxx-xxxxxxxxxxxxxxxxxxx-xxxxx=
> xxx-xxxxxxxxx]=20
> Lisa=20
> Piper<BR>(Cadence)<BR>&nbsp;v[xxxxxxxxxx-x-x-xx-xxxxxxx-x-xxxxx-x........=
> ..........]=20
> Erik=20
> Seligman<BR>(Intel)<BR>&nbsp;n[-----------x-x----x--------xxxx-----xxxx-x=
> x----------]=20
> Tej Singh (Mentor Graphics)&nbsp;=20
> v[xxx-xxxxxx-x-xxxxxx--xxxxxxxx-xxxxxxxxxxxxxxxxxxxxxxx] Bassam=20
> Tabbara<BR>(Synopsys)<BR>&nbsp;v[xxxxxxxxxxxxx-xxxxxxxxxxxxx-xxxxxxxxxx..=
> .............]=20
> Tom Thatcher (Sun Microsystems)<BR>&nbsp;&nbsp;=20
> |----------------------------------------------------- attendance=20
> on<BR>2008-02-12<BR>&nbsp;|----------------------------------------------=
> ---------=20
> voting eligibility for this=20
> ballot<BR>|-------------------------------------------------------- =
> e-mail=20
> votes<BR>received<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
> Legend:<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&n=
> bsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
> x =3D=20
> attended<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
> nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
> - =3D=20
> missed<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
> sp;&nbsp;&nbsp;&nbsp;&nbsp;=20
> r =3D=20
> represented<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
> p;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
> . =3D not yet a=20
> member<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
> sp;&nbsp;&nbsp;&nbsp;&nbsp;=20
> v =3D valid voter (2 out of last 3 or 3/4=20
> overall)<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
> nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
> n =3D not a valid=20
> voter<BR>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
> p;&nbsp;&nbsp;&nbsp;&nbsp;=20
> t =3D chair eligible to vote only to make or break a=20
> tie<BR>------------------------------------------------------------------=
> ---<BR>Intel=20
> Israel (74) Limited<BR><BR>This e-mail and any attachments may contain=20
> confidential material for the sole use of the intended recipient(s). Any =
> review=20
> or distribution by others is strictly prohibited. If you are not the =
> intended=20
> recipient, please contact the sender and delete all =
> copies.<BR><BR></P></FONT>
> <DIV><BR>-- <BR>This message has been scanned for viruses and =
> <BR>dangerous=20
> content by <A =
> href=3D"http://www.mailscanner.info/"><B>MailScanner</B></A>, and is=20
> <BR>believed to be clean. <BR></DIV>
> <DIV><SPAN class=3D877375115-18022008></SPAN>&nbsp;</DIV>
> <DIV><SPAN class=3D877375115-18022008><FONT face=3DArial =
> color=3D#0000ff>Append of=20
> earlier mail addressing comments from Lisa:</FONT></SPAN></DIV>
> <DIV><SPAN class=3D877375115-18022008>&nbsp;=20
> <P><FONT size=3D2>Hi Lisa,<BR><BR>please see my comments=20
> below.<BR><BR>Yaniv<BR><BR>-----Original Message-----<BR>From: Lisa =
> Piper [<A=20
> title=3Dblocked::mailto:piper@cadence.com=20
> href=3D"mailto:piper@cadence.com">mailto:piper@cadence.com</A>]<BR>Sent: =
> Saturday,=20
> February 16, 2008 01:30<BR>To: Havlicek John; sv-ac@eda.org<BR>Cc:=20
> doron.bustan@intel.com; eduard.cerny@synopsys.com; Fais Yaniv;=20
> dmitry.korchemny@intel.com; Manisha_Kulshrestha@mentor.com;=20
> johan.martensson@jasper-da.com; erik.seligman@intel.com;=20
> bassam.tabbara@synopsys.com; thomas.thatcher@sun.com<BR>Subject: RE: =
> call to=20
> vote on 2173<BR><BR>Why does this proposal add this to property but not =
> to=20
> sequences. The one example that is provided seems to be more appropriate =
> for a=20
> sequence.<BR><BR></FONT></P>
> <P><FONT size=3D2><FONT color=3D#0000ff>[Yaniv Fais] Although Mantis =
> 2173 asks to=20
> add the case construct to sequences and properties John and I decided at =
> this=20
> late stage to add the "case" construct to properties only (which maybe =
> extended=20
> to sequences later) - this is because properties already have a higher =
> level=20
> statement like "if...else" whereas sequences only have sequence =
> expressions with=20
> the sequence operators<BR></FONT><BR>In the VPI diagrams (36.45 Property =
> 
> specification) the blue "stmt"<BR>should be =
> "statement".&nbsp;</FONT></P>
> <P><FONT color=3D#0000ff size=3D2>[Yaniv Fais] I have notices throughout =
> clause 36=20
> (VPI diagrams) "stmt" is used consistently as an abbreviation for =
> statement=20
> whereas "expr" for expression (see 36.51 for example) therefore I =
> thought=20
> "property statement" should be "property stmt" much like there is =
> "atomic stmt"=20
> or "foreach stmt".</FONT></P><FONT size=3D2>
> <P><FONT face=3DArial color=3D#0000ff size=3D3></FONT><BR>Why was =
> property statement=20
> created instead of just adding this to property_expr.&nbsp; What was =
> lost by=20
> moving the if-else out from property_expr? I feel like I am missing=20
> something.<BR></P>
> <P><FONT face=3DArial color=3D#0000ff size=3D3>[Yaniv Fais] property =
> statement was=20
> created in order to avoid the addition of extra semicolons in uncommon =
> places -=20
> for example if "case" was added inside property_expr then it would be =
> required=20
> to write for example:</FONT></P>
> <P><FONT face=3DArial color=3D#0000ff size=3D3>property p;</FONT></P>
> <P><FONT face=3DArial color=3D#0000ff size=3D3>s |=3D&gt; </FONT></P>
> <P><FONT face=3DArial color=3D#0000ff size=3D3>&nbsp; case =
> (wait)</FONT></P>
> <P><FONT face=3DArial color=3D#0000ff size=3D3>&nbsp;&nbsp;&nbsp; =
> 1:...</FONT></P>
> <P><FONT face=3DArial color=3D#0000ff size=3D3>&nbsp; endcase =
> ;</FONT></P>
> <P><FONT face=3DArial color=3D#0000ff size=3D3>endproperty</FONT></P>
> <P><FONT face=3DArial color=3D#0000ff size=3D3>notice here there is an =
> extra semicolon=20
> after the endcase - this is uncommon in the language and we wanted to =
> avoid=20
> it.</FONT></P>
> <P><FONT face=3DArial color=3D#0000ff size=3D3></FONT>&nbsp;</P>
> <P><FONT face=3DArial color=3D#0000ff size=3D3>regarding moving if..else =
> out from=20
> property_expr to property statement : I think this is backward =
> compatible since=20
> property statement is also "property_expr ; " therefore the same syntax =
> which=20
> was allowed before is also allowed now - by making this change however =
> new=20
> syntax is added - for example:</FONT></P>
> <P><FONT face=3DArial color=3D#0000ff size=3D3>if (expr1)</FONT></P>
> <P><FONT face=3DArial color=3D#0000ff size=3D3>&nbsp; a |=3D&gt; =
> b;</FONT></P>
> <P><FONT face=3DArial color=3D#0000ff size=3D3>else</FONT></P>
> <P><FONT face=3DArial color=3D#0000ff size=3D3>&nbsp; a &amp;&amp; =
> b;</FONT></P>
> <P><FONT face=3DArial color=3D#0000ff size=3D3></FONT>&nbsp;</P>
> <P><FONT face=3DArial color=3D#0000ff size=3D3>In the past this was =
> illegal because of=20
> the semicolons but now the semicolons are <STRONG>optional </STRONG>, by =
> this=20
> proposal however it would be possible to put extra semicolons after =
> every=20
> property_expr so also "if (e1) q1;; else q2" is legal (this is written =
> in the=20
> comments addressed in the objective part of the proposal).</FONT></P>
> <P><FONT face=3DArial color=3D#0000ff size=3D3></FONT><FONT face=3DArial =
> color=3D#0000ff=20
> size=3D3></FONT><FONT face=3DArial color=3D#0000ff size=3D3></FONT><FONT =
> face=3DArial=20
> color=3D#0000ff=20
> size=3D3></FONT><BR>Lisa<BR><BR></P></FONT></SPAN></DIV></BODY></HTML>
> 
> ------_=_NextPart_001_01C8724C.D19F0600--

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
Received on Mon Feb 18 09:18:18 2008

This archive was generated by hypermail 2.1.8 : Mon Feb 18 2008 - 09:19:00 PST