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 12:12:12 2009
This archive was generated by hypermail 2.1.8 : Tue Jan 13 2009 - 12:12:29 PST