[sv-cc] RE: Corrected proposal for uwire

The issue here differs from that of monolithically rebuilding a whole
system. In the latter case, yes, you can change a #define and,
provided the rest of the system refers to it consistently, everything
will "just work".

Users of VPI, however, typically build asynchronously from the
simulator that they're interfacing to. In fact, a third-party provider
may have to interface to multiple releases of the same simulator.
Thus, if one release uses vpiNone = 12 and another uses vpiNone = 13,
vendors will either have to conditionalize the code per release or
provide distinct modules for the two releases.

For this reason, IMO, we will cause the users less trouble if we keep
vpiNone = 12.

Regards,
Jim Vellenga

---------------------------------------------------------
James H. Vellenga 978-262-6381
Engineering Director (FAX) 978-262-6636
Cadence Design Systems, Inc. vellenga@cadence.com
270 Billerica Rd
Chelmsford, MA 01824-4179
"We all work with partial information."
----------------------------------------------------------
  
 

] -----Original Message-----
] From: owner-ptf@boyd.com [mailto:owner-ptf@boyd.com] On
] Behalf Of Steven Sharp
] Sent: Friday, November 26, 2004 4:06 PM
] To: Kathy McKinley; Shalom.Bresticker@freescale.com
] Cc: btf@boyd.com; ptf@boyd.com
] Subject: Re: Corrected proposal for uwire
]
]
] >Regarding the Annex G change, I think that change would
] break existing code.
] >I think it would have to be
] >
] >#define vpiNone 12 /* no default net type (1364-2001) */
] >#define vpiUwire 13 /* unresolved wire net (1364-2005) */
]
] The usual purpose of providing defines in a header file is so
] that users
] will use the mnemonic names, and their code becomes independent of the
] numerical values that encode them. So this should not cause a problem
] for VPI code being recompiled with the new header. The only
] problem would
] be legacy object code compiled with the old 1364-2001 header
] but run in
] a 1364-2005 simulator.
]
] I will include the PTF on this, since this really falls into
] their area.
] Is it better to keep the definition of vpiNone numerically
] unchanged, or
] is it better to keep all the actual net types together, with
] vpiNone at
] the end?
]
] Steven Sharp
] sharp@cadence.com
]
]
]
Received on Mon Nov 29 07:03:35 2004