Hello Chuck, thanks for this feedback. I have interspersed some comments into your response. My main point was that the "default" behavior should be configurable by the user, which will mitigate a lot of problems when working with older applications ... Many thanks for all your hard work on this Best regards, -Michael Chuck Berking wrote: > 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. YES > > 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. I guessed that; this is the reason for my statement "... (because they are /mapped to another structure,/ *great*) ..." > > 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. ... and accessing this property with a (at a minimum 2001, but also 2005) earlier version should NOT cause an error but this property can be gracefully synthesized, even if absent in the database. > 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 > -- 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 09:00:23 2007
This archive was generated by hypermail 2.1.8 : Thu Apr 12 2007 - 09:00:52 PDT