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.Received on Tue Jan 13 10:27:58 2009
This archive was generated by hypermail 2.1.8 : Tue Jan 13 2009 - 10:28:16 PST