Sorry. I didn't take this into account and I have no intent to break the compatibility mode. If we can make selective changes and preserve this mode, that makes much more sense than gratuitous change to break it. > -----Original Message----- > From: Jim Vellenga [mailto:jvellenga@verizon.net] > Sent: Tuesday, January 13, 2009 11:47 AM > To: Shields, John > Cc: Chuck Berking; Bresticker, Shalom; stuart@sutherland-hdl.com; SV-CC > Subject: Re: [sv-cc] Annex N (sv_vpi_user.h) correction summary > > I'm hoping Michael Rohleder will be able to attend this meeting. He was > the one who got us motivated to introduce the compatibility mode. The > scenario he got us to address was where the simulator vendor has to > support multiple modes, including at least one default mode for > applications > that can no longer be recompiled. > > Yes, that's right -- can no longer be recompiled. If we do a drastic > thoroughgoing renumbering, vendors can make the choice, but most will > need to maintain the old numbering(s) as well. > > At this point I tend mostly to agree with Abi's last post. > > One of the flaws I see with some of the posted arguments is that > renumbering is seen as an all or nothing choice. And since some > #define's must be renumbered, or because we have chosen to renumber > some others, then (if we do assume that renumbering is all or nothing) > it only makes sense to do the renumbering. > > But if we are not limited to all-or-nothing renumbering, we can limit > our renumbering to those areas where renumbering really is required, > which will tend to be the later additions -- and will not really > affect most legacy applications anyhow. > > And this will (for those companies which are vendors) still have the > advantage of simplifying the compatibility mode adaptations over > a wholesale renumbering. > > Regards, > Jim Vellenga > > ----------------------------------------------------------------------- > Jim Vellenga (jvellenga@alum.mit.edu) > Senior software engineer for team-based development; skilled at team- > building while retaining a detailed technical knowledge of the project > itself. Excellent at negotiating clear definitions (standards, > interfaces, etc.) across functional and industry boundaries. > 781-646-6778 > ----------------------------------------------------------------------- > > > > John Shields wrote: > > Hi, > > > > The header file, having changes that matter, will require some > > applications to recompile anyway. When we reasonably expect that > > situation to be prevalent, we should not fear any change to the > > numbering of manifest constants. It is not unreasonable to require > > vpi applications to be recompiled with a major new release of the LRM. > > Not at all. It is likely to be driven by desire to support new > > features anyway. If you are worried that you can't make the edits > > without typos and iteration, that is another matter, but even that > > should converge quickly. > > > > This binary compatibility was aimed at product release cycles where > > the spec had minor revision and you didn't want to trigger a cascade > > of re-release of vpi applications. There is a larger issue here. We > > should get the ranges right with flexibility for revision going forward. > > > > I therefore agree with Stu and Shalom. My 2 cents. > > > > Regards, John > > > > Chuck Berking wrote: > >> 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* <http://www.mailscanner.info/>, 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 16:59:36 2009
This archive was generated by hypermail 2.1.8 : Tue Jan 13 2009 - 16:59:55 PST