Michael- Great points- thanks ! I happened to see Jim's email first, so I had not seen this yet, FYI. I agree with all your feedback. I will integrate this accordingly in my next proposal version. I would only have the following to add to your "refinements of requirements" (the "However" section): I believe there *are* provisions in the standard already for at least some of your requirements here. For example, there is no requirement for issuing error messages for use of deprecated items; this could be a lint-like VPI-provider optional feature. As for the vpiMemory and vpiMemoryWord cases, these object types are directly replaced by the more general vpiRegArray and vpiReg types in 1364-2005 & 1800-2005. Any application running in these modes would never encounter the older vpiMemory or vpiMemoryWord objects as such. They are identifiable, however, with the vpiIsMemory property available for vpiRegArray, and vpiParent of a vpiReg of such an array, respectively. Iterations based on these types are of course still available (== the best way to selectively find them in a scope). So, as long as the application doesn't care about the *type* of objects it gets in such iterations, it should be happy. vpiMultiArray property is a bit different, only because it seems to have been *absent* in recent standards rather than merely deprecated. Moreover it was barely formalized in 2001 to begin with. All that said, I see no reason it couldn't operate as a deprecated property, at least into the 2005 standards. Regards, Chuck ________________________________ 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 08:51:57 2007
This archive was generated by hypermail 2.1.8 : Thu Apr 12 2007 - 08:52:52 PDT