RE: [sv-cc] Annex N (sv_vpi_user.h) correction summary

hi all
I don't think I will ever agree that renumbering is a good idea. I understand that as it gets more mixed up, it gets harder to determine which number-set a new item is in, but that's fixable. The tool vendors would still have to maintain backwards compatibility after renumbering so we would have to have two sets of numbers; debugging something with a setup like that would be horrendous. And there would not really be any user gain at all, since the users use the names, not the numbers.
Abi


-----Original Message-----
From: owner-sv-cc@server.eda.org on behalf of Chuck Berking
Sent: Mon 1/12/2009 1:18 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.




-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.