There is an incompatibility introduced by 1503 as you mentioned (vpiIdentifier has morphed into vpiSeqFormalDecl, and vpiPropFormalDecl objects), but this only affects existing applications using vpiIdentifier. Speaking of the VPI Compatibility features themselves (36.12- motivated by inputs from Michael Rohleder as Jim mentioned), a full renumbering would render this scheme inoperative as specified. To retain this capability, vendors would be required to support two versions of the sv_vpi_user.h header in the VPI compilation environment for each 1800-2009-compatible release, as well as a modified scheme to support this. Granted, the change I first mentioned for vpiIdentifier should be in the 36.12 compatibility table for 2009, but its omission would seem to incur a much smaller penalty than an optional renumbering would. Regards, Chuck -----Original Message----- From: owner-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On Behalf Of Stuart Sutherland Sent: Tuesday, January 13, 2009 1:27 PM To: 'SV-CC' Subject: RE: [sv-cc] Annex N (sv_vpi_user.h) correction summary I agree that resequencing should only take place if something in the proposed 2009 file already requires that applications based on 1800-2005 be recompiled. I think that is the case. If my memory serves me correctly (and it fails a lot, lately) some of the Mantis items that I implemented have either changed the value of existing constants, or changed the name of a constant but retained the value of the old constant. Mantis 1503 made some of these types of changes. Its effects are evident in the colored version of Draft 7. Am I wrong in thinking that these types of changes will require 1800-2005 applications be recompiled to run on 1800-2009 tools? 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: Tuesday, January 13, 2009 8:53 AM > To: Bresticker, Shalom; stuart@sutherland-hdl.com; SV-CC > Subject: RE: [sv-cc] Annex N (sv_vpi_user.h) correction summary > > 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 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. > > > > > > > > -- > > 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 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. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Tue Jan 13 13:57:12 2009
This archive was generated by hypermail 2.1.8 : Tue Jan 13 2009 - 13:57:30 PST