Jim- Thanks for all your inputs- will do. It's clear we need the header file text included. Further thinking on this convinces me it has to be vpi_user.h rather than vpi_sv_user.h. Even though a case could be made for requiring any app to add the SV include file, it implies a source code change in addition to recompilation (which, I'm guessing Michael would not be happy about!). That said, will older applications (using compatibility mode) still compile and build OK *without* including vpi_sv_user.h in an 1800-2005 environment ?? I believe they *must*, but I certainly could be overlooking something here... Regards, Chuck ________________________________ From: Jim Vellenga Sent: Thursday, April 12, 2007 9:12 AM To: Michael Rohleder; Chuck Berking Cc: Moorhouse, Abigail; SystemVerilog CC DWG Subject: RE: Are we all thinking of the same use model for compatibility modes? Lots of good suggestions here -- and lots of good preliminary work by Chuck and by Abi. Ok, the whole thing is making sense to me now. It would be good to combine some sample header file changes like Abi made with Chuck's latest proposal. That'll make the whole thing much clearer to committee members like me who haven't thought it through as clearly, and will help to speed discussion. Incidentally, including the explicit error checks such as #ifdef VPI_VERSION_COMPATIBILITY_REQUEST_2008 #ifdef VPI_VERSION_COMPATIBILITY_REQUEST_2005 #error "Only zero or one of VPI_VERSION_COMPATIBILITY_REQUEST_{2008|2005|2001} may be defined" #else #ifdef VPI_VERSION_COMPATIBILITY_REQUEST_2001 #error "Only one of VPI_VERSION_COMPATIBILITY_REQUEST_{2008|2005|2001} may be defined" #endif #endif #endif (or the equivalent for Chuck's proposed names) in the standard header file will make it unnecessary to include the statement "It shall be a compile-time error to define more than one of the above symbols for compiling any VPI application source code" in the text of the standard. Since the vpi_user.h is normative rather than informative, that will automatically take care of generating the compile-time error. I would encourage Chuck to add at least part of the specific forms of the header file changes to his proposal and recirculate it in order to help the discussion along. A lot of people are like me, I think, in benefitting from seeing things in concrete form. I would also include a code excerpt such as Abi wrote that shows #define'ing the appropriate feature before including vpi_user.h (and sv_vpi_user.h, when appropriate). Regards, Jim --------------------------------------------------------- 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." ---------------------------------------------------------- ________________________________ From: Michael Rohleder [mailto:michael.rohleder@freescale.com] Sent: Thursday, April 12, 2007 8:46 AM To: Chuck Berking Cc: Moorhouse, Abigail; Jim Vellenga; SystemVerilog CC DWG Subject: Re: Are we all thinking of the same use model for compatibility modes? Hi all, I very much agree with everything said here. I especially very much like Abi's NO to the questions " Will the application provider have to compile with a different vendor-specific header file for each separate vendor?" and "Or do we want to leave this all deliberately vague?" This is important, at least for me. There is a small disagreement with Abi, your proposal is not a counter-proposal to mine, I think it is more a (very good) refinement. And I would like to refine my requirements a little more: - the simulator is working in a default mode, which should be made configurable by the user. So an user should have the capability to define the default mode assumed by a simulator. - I understand that it is impossible that an application compiled for an earlier version of the standard will support features of a more recent version. It is hard to identify the appropriate handling for corresponding objects so we leave most of this unspecified. - However there are several objects that have been deprecated from earlier versions. Here it would be great to define a graceful behavior for these objects in later versions of the standard, and this is exactly what I would like to request. Basically there should be a way to properly map 1) vpiMemory, 2) vpiMemoryWord, and 9) vpiMultiArray behavior, so it can also behave well in a more recent simulator environment. It would be great to have a setting that permits the usage of these objects in a sort of compatibility mode, eventually this needs to be explicitely requested by the user. When it is not possible that these transitions occur (because they are mapped to another structure, great). If it can occur, and there is a way to avoid an error for these cases, we should do it. With respect to Chuck's proposal: - this looks mostly fine with me. I would suggest to state that the method in 36.1.2/of Abi can only deal with incompatibilities by recompiling the VPI application. We should clearly state that this does not solve any compatibility problem of a compiled application (this should be partially possible by making the default mode configurable). We should also clearly state that it is an error to access an object not yet defined by an earlier version of the standard with an application that has been compiled for this earlier version. The behavior will be unpredictable. We shall also state that the behavior of such an application shall be deterministic as long as only objects defined by the earlier standard version are accessed. - Last but not least we should define an 1800-2008 version as well. :-D Some more food for thought. Best regards, -Michael Chuck Berking wrote: I was just beginning to respond in-kind. I agree with this; my intent was certainly to support the scheme you had proposed, Abi. It *does* mean specifying a new vpi_user.h header file in the standard itself, which initially I had hoped we could avoid, but I agree with your answers below. -CB -----Original Message----- From: Moorhouse, Abigail [mailto:abigailm@model.com] Sent: Wednesday, April 11, 2007 5:10 PM To: Jim Vellenga; Chuck Berking; Michael Rohleder Subject: RE: Are we all thinking of the same use model for compatibility modes? hi Jim According to my proposal, here would be the answer to your questions: Are we going to modify the standard vpi_user.h so that it has all the necessary conditional compilation? - Abi - YES Or are we going to require the vendors to provide the necessary substitutes, but leave the content of each substitute to the discretion of the vendor? - Abi - NO Will the application provider have to compile with a different vendor-specific header file for each separate vendor? - Abi NO, this would be a very bad solution I think Or do we want to leave this all deliberately vague? - Abi - NO again, we want a well-defined solution that is cross-vendor, and the simplest possible for the user (Note that the names in my original proposal don't quite match Chucks choices, it's a proof-of-concept suggestion). Abi -----Original Message----- From: Jim Vellenga [mailto:vellenga@cadence.com] Sent: Wednesday, April 11, 2007 1:25 PM To: Chuck Berking; Moorhouse, Abigail; Michael Rohleder Subject: RE: Are we all thinking of the same use model for compatibility modes? Ok, let's go to three applications. Let's say that the user has an old application that they no longer have a source or vendor for, so they choose the default mode to be 1364-1995. Then Vendor v explicitly compiles Application A for 1800=2005 mode, while Vencor w has explicitly compiled Application B for 1364-2005 mode (they're a little behind the curve). So our vision is that the user can run the old application, Application A, and Application B all at the same time. I think this is what everyone is saying, and I think it's what Michael has siad that he wants as a user. So the overall goal seems clear. So let's work with this as a base. Chuck, in your proposal you didn't specify a mechanism for letting all three run together. Abi did. She mentioned creating a routine vpi_handle_1364v2005(), which I think works fine if we can get there. Now I'm wanting to know how we plan to specify the mechanism. Are we going to modify the standard vpi_user.h so that it has all the necessary conditional compilation? Or are we going to require the vendors to provide the necessary substitutes, but leave the content of each substitute to the discretion of the vendor? Will the application provider have to compile with a different vendor-specific header file for each separate vendor? Or do we want to leave this all deliberately vague? Regards, Jim --------------------------------------------------------- James H. Vellenga 978-262-6381 Architect (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: Chuck Berking ]Sent: Wednesday, April 11, 2007 2:26 PM ]To: Moorhouse, Abigail; Jim Vellenga; Michael Rohleder ]Subject: RE: Are we all thinking of the same use model for ]compatibility modes? ] ]YES- these are my assumptions too! I agree with your initial ]assertions, Jim (these apply to explicitly "mode-compile-bound" ]applications), and your "re-statement" of them, Abi. I.e. I don't ]see these two versions being in conflict. Do you agree Jim ? ]-CB ] ]-----Original Message----- ]From: Moorhouse, Abigail [mailto:abigailm@model.com] ]Sent: Wednesday, April 11, 2007 1:22 PM ]To: Jim Vellenga; Chuck Berking; Michael Rohleder ]Subject: RE: Are we all thinking of the same use model for ]compatibility modes? ] ]hi Jim ]Here are my assumptions ] ]1. The *simulator* can run in a single, default compatibility mode, ]which the user can choose. ]2. If there are multiple applications, needing different modes, ]recompilation with explicit mode-selection can be avoided for only one ]mode, however many applications this affects ]3. As a corollary, it will never be possible to run two applications, ]requiring two different modes of operation, without ]recompiling at least ]one of them to explicit select the mode. ] ]In your example, yes the following is possible, as long as at least one ]of the compilations was an explicit compilation using the new ]functionality. ] ]I think we may need to develop new terminology. Perhaps we ]need to state ]whether or not the application was explicitly compiled within a ]compatibility mode, rather than implicitly so? When a VPI developer ]calls vpi_handle or whatever, they are implicitly assuming one of the ]LRM versions, but the simulator doesn't really know which. ]When they use ]the #define they actually will call vpi_handle_1364v2005 or ]whatever, so ]now the simulator has more information, and this information is ]effectively supplied from the user application. ] ]Abi ] ] ]-----Original Message----- ]From: Jim Vellenga [mailto:vellenga@cadence.com] ]Sent: Wednesday, April 11, 2007 10:14 AM ]To: Moorhouse, Abigail; Chuck Berking; Michael Rohleder ]Subject: Are we all thinking of the same use model for compatibility ]modes? ] ]Abi and Chuck, ] ]Given a couple of passing comments from each of you, I'm ]wondering if we ]are all working with the same underlying use model for compatibility ]mode. ] ]Are we all assuming that the following is possible? ] ]-- Application A has been compiled to run in 1364-1995 mode. ] ]-- Application B has been compiled to run in 1800-2005 mode. ] ]-- The user runs both applications together on a single design in a ]single run of the simulator. ] ]To put it another way, the compatibility mode is a characteristic of ]each application and not a characteristic of the simulator. So the ]simulator is responding to Application B in 1800-2005 mode and to ]Application A in 1364-1995 mode. ] ]Are we all expecting that to be true? ] ]Regards, ]Jim ] ]--------------------------------------------------------- ]James H. Vellenga 978-262-6381 ]Architect (FAX) 978-262-6636 ]Cadence Design Systems, Inc. vellenga@cadence.com ]270 Billerica Rd ]Chelmsford, MA 01824-4179 ]"We all work with partial information." ]---------------------------------------------------------- ] -- NOTE: The content of this message may contain personal statements which are not neccessarily the view of Freescale, unless specifically stated. ___________________________________________________ | | | Michael Rohleder Tel: +49-89-92103-259 | / )| Principal Staff Engineer Fax: +49-89-92103-101 |( \ / / | Freescale Semiconductor, www.freescale.com | \ \ _( (_ | _ New Product Development Center _ | _) )_ (((\ \>|_/ > Schatzbogen 7, D-81829 Muenchen, Germany < \_|</ /))) (\\\\ \_/ / mailto:michael.rohleder@freescale.com \ \_/ ////) \ /_______________________________________________\ / \ _/ \_ / / / \ \ This e-mail, and any associated attachments have been classified as: [ ] Public [ ] Freescale Semiconductor Internal Use Only [ ] Freescale Semiconductor Confidential Proprietary Freescale Halbleiter Deutschland GmbH Schatzbogen 7 D-81829 Muenchen www.freescale.com Sitz der Gesellschaft/Registered Office: Muenchen Registergericht/Registered Court: Amtsgericht Muenchen HR B 151590 Geschaeftsfuehrer/General Manager: Juergen Weyer, Karen Roscher, John Pence, Oliver Kaltenbach, Andreas Wild USt.-ID-Nr./VAT-ID-No. DE813898243 Steuernummer/Tax No. 143/138/30552 -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Thu Apr 12 07:49:24 2007
This archive was generated by hypermail 2.1.8 : Thu Apr 12 2007 - 07:50:21 PDT