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.