Tapati, We did have a big discussion about this, and our conclusions are contained in part in the expanded Note 19 of "32.14 Variables", which is in the version, I believe, circulated for the first ballot. In this case, yes, the application developer should rewrite the code. But there is a catch: Note 19 deliberately allows a simulation product to return different values for vpi_get_str(vpiReg, ...). So it can depend on which simulator you're using, or on a command line switch in a particular simulator, or even, strictly speaking, on the time of day. An application that wants to run both with a SystemVerilog simulator and a plain old vanilla Verilog simulator may need to conditionalize its code with something like #ifdef vpiLogicVar Note that similar conflicts occur for vpiVarBit vs. vpiRegBit and for vpiArrayVar vs. vpiRegArray. Regards, Jim V. --------------------------------------------------------- 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-sv-cc@eda.org [mailto:owner-sv-cc@eda.org] On ] Behalf Of Tapati Basu ] Sent: Friday, May 27, 2005 5:30 PM ] To: sv-cc@eda.org ] Cc: Tapati.Basu@synopsys.com ] Subject: [sv-cc] vpiReg and vpiLogic ] ] ] Hi, ] ] I just noticed that we are now treating vpiRegVar and ] vpiLogicVar the same way. ] That means both of them will be the same constant in the ] header file. Now what ] happens if user has this code already for SV ? ] ] case vpiReg : ] printf( vpiReg) ] ] case vpiLogic : ] printf(vpiLogic) ] ] ] We will get a duplicate case error here. Do we suggest them ] to just change ] their code ? ] ] ] What is our decison, by default what should ] vpi_get_str(vpiType..) will give ] for logic/reg handle ? Should it be vpiLogic or vpiReg ? ] ] - Regards, ] Tapati ] ] ]Received on Tue May 31 05:27:57 2005
This archive was generated by hypermail 2.1.8 : Tue May 31 2005 - 05:28:17 PDT