Hi Bassam, have you seen my reply to Lisa ? (it also took time to show in the reflector) I appended it to this mail so please comment if there is anything you disagree on so we can converge for the next vote. 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. Thanks, Yaniv ________________________________ From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com] 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, 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. ** 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. Thx. -Bassam. ________________________________ 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!==b1 && b!==b2)" 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) 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 = 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 --------------------------------------------------------------------- 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 <http://www.mailscanner.info/> , and is believed to be clean. Append of earlier mail addressing comments from Lisa: 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". [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 |=> 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. 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 |=> b; else a && b; 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 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Feb 18 08:17:09 2008
This archive was generated by hypermail 2.1.8 : Mon Feb 18 2008 - 08:17:22 PST