If the 2009 sv_vpi_user.h is not backward compatible with existing compiled applications (meaning existing applications will need to be recompiled), would it make sense to re-sequence all of the numbering at this time? Stu ~~~~~~~~~~~~~~ Stuart Sutherland stuart@sutherland-hdl.com (503) 692-0898 > -----Original Message----- > From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Chuck > Berking > Sent: Monday, January 12, 2009 12:45 PM > To: SV-CC > Subject: [sv-cc] Annex N (sv_vpi_user.h) correction summary > > All- PLEASE REVIEW for Wed's meeting ! > After a thorough review of the latest sv_vpi_user.h changes in p1800 > Draft 8, I recommend the changes noted below. Please note that this > supersedes my previous email, as some different numbers and many more > corrections are needed than previously thought. > > 1) vpiAllocScheme correction: > > #define vpiAllocScheme 4 --> 658 > > WHY: > My previous note suggested 656 for this, but 656 and 657 are > already taken: > #define vpiOpStrong 656 /* strength of temporal operator */ > #define vpiIsDeferred 657 > > 2) New dynamic object callback type corrections: > > #define cbCreateObj 606 --> 700 > #define cbReclaimObj 607 --> 701 > #define cbEndOfObject 607 --> 702 > > WHY: > a) Corrects error with cbEndOfObject duplicating cbReclaimObj > b) Avoids collision with assertion callback types: > /* assertion callback types */ > #define cbAssertionStart 606 > #define cbAssertionSuccess 607 > #define cbAssertionFailure 608 > c) Choice of 700 - 702 leaves 659 - 699 gap to accommodate more > assertion types in their own contiguous section. > > 3) New property type >= 900 > > #define vpiIsCoverSequence 900 --> 659 > > WHY: No need to enter the 900+ range yet, since slack still > exists in SV property numbering. > > 4) New object types MISSING for section 37.34 (Constraint exprs) > > #define vpiConstraintExpr 747 > #define vpiElseConst 748 > #define vpiImplication 749 > #define vpiConstrIf 738 > #define vpiConstrIfElse 739 > > WHY: These were accidentally omitted from the header ! > > -- > This message has been scanned for viruses and > dangerous content by MailScanner, and is > believed to be clean. > > > > -- > This email was Anti Virus checked by Astaro Security Gateway. > http://www.astaro.com -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Mon Jan 12 13:03:10 2009
This archive was generated by hypermail 2.1.8 : Mon Jan 12 2009 - 13:03:15 PST