RE: [sv-cc] RE: [sv-ac] Draft P1800/D9-preliminary review

From: Korchemny, Dmitry <dmitry.korchemny_at_.....>
Date: Mon Jul 13 2009 - 21:58:56 PDT
Thanks for clarifying this.

Dmitry

From: Chuck Berking [mailto:berking@cadence.com]
Sent: Monday, July 13, 2009 6:18 PM
To: Korchemny, Dmitry; Lisa Piper
Cc: sv-ac@server.eda.org; sv-cc@eda-stds.org
Subject: RE: [sv-cc] RE: [sv-ac] Draft P1800/D9-preliminary review

Dmitry, Lisa-
vpiIsCoverSequence is a VPI property- not a method.  vpiClockedSeq is a VPI object and a VPI method.  VPI property numbering is allowed to overlap with VPI methods/object numbering, so these definitions are not in conflict.

FYI- (re. Mantis 2572 changes) we changed the VPI property numbers greater than 900, since there was plenty of numbering slack available below 900 (as per my comment), i.e. there was no need to leave so many "holes".  The object/method numbering, however, was out of numbers below 900, so those were left as-is.
Regards,
Chuck Berking (SV-CC)


________________________________
From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Korchemny, Dmitry
Sent: Thursday, July 09, 2009 11:02 AM
To: Lisa Piper
Cc: sv-ac@server.eda.org; sv-cc@eda-stds.org
Subject: [sv-cc] RE: [sv-ac] Draft P1800/D9-preliminary review
Thanks, Lisa,

Probably, vpiIsCoverSequence, is a method since it qualifies the cover statement - whether it is a cover property or a cover sequence. I am CC'ing SV-CC to comment.

Dmitry

From: Lisa Piper [mailto:ljpiper619@aol.com]
Sent: Thursday, July 09, 2009 5:51 PM
To: Korchemny, Dmitry
Cc: sv-ac@server.eda.org
Subject: RE: [sv-ac] Draft P1800/D9-preliminary review

Hi Dmitry,

Mantis 2541:  changes complete

16.14 review: no issues found

Annex N:  I just looked at assertion related stuff.  The original mantis item states:
New property type >= 900

   #define vpiIsCoverSequence 900

   WHY: No need to enter the 900+ range yet, since slack still exists in SV property numbering.

The only significant change was the define value for vpiIsCoverSequence. The new value
is the same as vpiClockedSeq, which may be ok since one is an object type and the other is a method and it says these numbers may overlap. I'm just not sure why vpiIsCoverSequence is a method.

#define vpiClockedSeq 659
.
#define vpiIsCoverSequence 900 659

In addition, I noticed that there are others that have numbers in the 900's that were not changed

#define vpiRestrict 901
#define vpiClockedProp 902
#define vpiLetDecl 903
#define vpiLetExpr 904
#define vpiCasePropertyItem 905 /* property case item */

Lisa

________________________________
From: owner-sv-ac@server.eda.org [mailto:owner-sv-ac@server.eda.org] On Behalf Of Korchemny, Dmitry
Sent: Thursday, July 02, 2009 8:58 AM
To: sv-ac@server.eda.org
Subject: [sv-ac] Draft P1800/D9-preliminary review

Hi all,

It is time to review Draft P1800/D9.

Each SV-AC member is requested to review the implementation of Mantis items assigned to him/her, and in addition the assigned fragment of the LRM. The review is due by 07/10/2009. Please, send a notification when you are done, with the list of issues found or with the indication that the implementation is correct. If you find an issue with Mantis implementation, please, add a corresponding note to the Mantis with the indication of the actions required from the editor, and move the Mantis to the Editor status. If no issues have been found, keep the Mantis unchanged.

Mantis list:
2661 "Syntax 16-19" is in blue                                                                                                                     Dmitry Korchemny
2660 Add indices to expressions                                                                                               Doron Bustan
2659 Backward compatibility issue with sequence property                                                          Doron Bustan
2658       Default values for untyped formals                                                                                         Dmitry Korchemny
2656 Clarify difference of $global_clock handling in simulation and formal verification Tom Thatcher
2652 Future value functions need clarification                                                                    Erik_Seligman
2650 Ambiguity in a sequence repetition [*0] definition                                                 Erik_Seligman
2612       `true should have a backtick in a sequence example                                                        Dmitry Korchemny
2541 syntax errors - missing parenthesis                                                                                               Lisa Piper
2516 Another contradiction of existing text with 2398 needs to be fixed                                 Erik_Seligman
2486 Scope of Annex F definition of "specify" is not clear.                                                             john_havlicek
2478       Clock flow subclause is not consistent with multiclocked property definition      Dmitry Korchemny

Fragments:
Clause 3 (relevant parts) - Tapan
Clause 15 (relevant parts) - Manisha
Clause 16
Beginning - 16.8 (including) Ed
                16.9 Ben
                16.10 - 16.12 (including), 16.17 - Manisha
                16.13 - Doron
                16.14 - Lisa
                16.15 - Tom
                16.16 - 16.18 (including)  Dmitry
Clause 17 - Erik
Clause 20 (relevant parts) - Manisha
Clause 37 (relevant parts) - Bassam
Clause 39 - Bassam
Annex A - Tapan
Annex B - Tapan
Annex C - Tapan
Annex F - John
Annex N - Lisa

Please, notify me if you are unable to review the assigned fragments/Mantis items.

Thanks,
Dmitry

---------------------------------------------------------------------

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.

---------------------------------------------------------------------

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.
---------------------------------------------------------------------
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 Mon Jul 13 22:01:49 2009

This archive was generated by hypermail 2.1.8 : Mon Jul 13 2009 - 22:02:12 PDT