Hi Bassam, 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. 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. Thanks, Yaniv ________________________________ From: Bassam Tabbara [mailto:Bassam.Tabbara@synopsys.com] 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, 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. As to the 1st this is *not* backward compatible as far as VPI -- you now have the extra property statement wrapper. Thx. -Bassam. ________________________________ From: Fais Yaniv [mailto:yaniv.fais@freescale.com] 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, 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:40:49 2008
This archive was generated by hypermail 2.1.8 : Mon Feb 18 2008 - 08:41:01 PST