Shalom- Renumbering or re-sequencing (as I presume Stu and I had understood it) in this case would imply we would be changing the range conventions, rendering compiled 1800-2005 applications incompatible. For example, we are out of number assignments for 600 -> 749, which we have allocated for new SV "model extensions" (objects and methods): [ Conventions in sv_vpi_user.h header comments ... ] /*********************************************************************** **** * NOTE: * The constant values 600 through 999 are reserved for use in this file. * - the range 600-749 is reserved for SV VPI model extensions * - the range 750-779 is reserved for the Coverage VPI * - the range 800-899 is reserved for the Reader VPI * Overlaps in the numerical ranges are permitted for different categories * of identifiers; e.g. * - object types * - properties * - callbacks ************************************************************************ **/ Thus, we would presumably move the Coverage assignments forward 50 slots or so to keep the SV objects & methods contiguous, etc. The upshot of this is that 1800-2005 applications (at least coverage and assertions, etc) would be rendered totally incompatible. The potential for new errors to be introduced at this late time would also be (IMO) not worth the risk. Does this help to clarify things ? Regards, Chuck -----Original Message----- From: Bresticker, Shalom [mailto:shalom.bresticker@intel.com] Sent: Tuesday, January 13, 2009 2:51 AM To: Chuck Berking; stuart@sutherland-hdl.com; SV-CC Subject: RE: [sv-cc] Annex N (sv_vpi_user.h) correction summary I'm confused. If all the problems are in items that are new in 1800-2009, wouldn't it make more sense to fix them in 2009, before there are problems with back compatibility, which is what will happen if we wait till 2012? Regards, Shalom-----Original Message----- From: owner-sv-cc@server.eda.org [mailto:owner-sv-cc@server.eda.org] On Behalf Of Chuck Berking Sent: Monday, January 12, 2009 11:19 PM To: stuart@sutherland-hdl.com; SV-CC Subject: RE: [sv-cc] Annex N (sv_vpi_user.h) correction summary IMHO- Inasmuch as my sense of order is tempted to do this, I *don't* think renumbering is a good idea at this time. These changes all have to do with assignments either NEW with D7/7a, or missing in 1800 entirely (#4 below), so they are NOT incompatible with 1800-2005.Apps must recompile to get the latest stuff, as always, but most 1800-2005 apps will still work. This said, renumbering should certainly be our first step in gearing up for 2012 or whatever. Regards, Chuck -----Original Message----- From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Stuart Sutherland Sent: Monday, January 12, 2009 4:03 PM To: 'SV-CC' Subject: RE: [sv-cc] Annex N (sv_vpi_user.h) correction summary 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 changesin p1800Draft 8, I recommend the changes noted below. Please notethat thissupersedes my previous email, as some different numbers andmany morecorrections 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. -- This message has been scanned for viruses and dangerous content by MailScanner, 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 archive was generated by hypermail 2.1.8 : Tue Jan 13 2009 - 10:29:44 PST