Thanks, Scott. I agree apart from one small point (with regard to backchannel) namely: The standard functionality mode is compliant (or portable). The enhanced proprietary functionality mode is not compliant (or not portable). Again, it's the "why bother?" point. If an IC vendor invests in R&D, adds that expensive silicon real estate, and models the backchannel, it's seems to me that backchannel is the quintessence of the chip. If you run the model in question outside its target simulator, it gives the wrong answer, which is worse than not running at all. To me, that's the definition of a non-compliant (or non-portable) model. (Sorry to belabor the point) From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow Sent: Monday, May 02, 2011 9:41 AM To: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: IBIS-AMI Model Portability I sent this to Mike over the weekend, somehow managing to not send it to the list. I'm not sure that the BIRD makes any existing models not-compliant at all. That remains to be seen. Do you personally know of any models out there that use Out or InOut parameters to alter flow or results? If they do not, they are still compliant. I don't know the specifics of the Gennum Backchannel model, but we can all agree that that model is using mechanisms that alter flow or results, and that currently that functionality is non-compliant, or using Todd's better word, non-portable. The model would still load into other EDA tools and be capable of use in a "standard functionality" mode, where the backchannel functionality is disabled. But the full intended functionality of the model would not be achieved in any but the original target simulator. The standard functionality mode is compliant (or portable). The enhanced proprietary functionality mode is not compliant (or not portable). If we agree that IBIS as a portability specification, then a desired function of the specification is to encourage modelers to use portable constructs whenever possible, and highlight instances when they are using non-portable constructs. It is also a desired function that the specification encourage modelers to submit non-portable constructs for standardization through the BIRD process. Finally it is a desired function of the IBIS committees involved to guide the BIRD process to standardization of generalized constructs that cover specific current needs and future needs, to avoid a "hodgepodge" of keywords, parameters, ... etc, that have only one specific usage. These have always been the goals of IBIS specifications. There are plenty of enhancements that were introduced by EDA vendors or model makers that were approved nearly as-is, with little modification, and plenty of enhancements that were introduced that were approved with significant modifications, requiring the original submitter to change their models to meet the specification and write code to use the new format in EDA tools. There are also plenty of parties who have ignored the specification process altogether, and used comment line keywords to allow users to add proprietary functionality into distributed and existing models, in order to support proprietary simulator features. It is well-known that these features are non-portable. Usually, however, these proprietary features were added into models by the user, who could edit the ASCII text files. In the early days of IBIS portability issues came up all the time. There was IBIS, and there was Quad Design. Quad Designs model format was proprietary and different from IBIS. It's models were not portable to IBIS simulators. There were two solutions to this problem. First, features unique to Quad models were often standardized in IBIS with an IBIS-specific format. Second, IBIS simulator vendors created Quad To IBIS translators. This solved both the specification problem and the portability problem, since there was a 1-to-1 mapping from one format to the other. Yet other simulator vendors, like Cadence, had their own internal proprietary format, DML. A translator from IBIS to DML, and I believe Quad to DML were used to solve that portability issue. Eventually the IBIS to DML translation was integrated and for all purposes the tool was an enhanced IBIS simulator, with many additional features under the covers. There was a point when IBIS became the accepted standard for I/O modeling, and even Quad had to create an IBIS to Quad translator, as Intel no longer supported the Quad format. Unfortunately, the model is no longer in the clear. A substantial portion of the model is in the hard-coded DLL, and cannot be modified by a translation script. Portability questions then arise in several ways: * When the model maker creates proprietary models with parameter names and formats to support new functionality, and the committee agrees to include those parameters in the spec at some future date, with minor or major alterations. * In this case, we can say that the original model is proprietary, and document that fact so that end-users and other EDA vendors are not surprised by the new functionality. * It is then each vendors' responsibility to determine whether it is in their best interest to incorporate those proprietary parameters, or wait until an IBIS specification is approved. * We can agree that once a specification for the functionality has been approved, that new models going forward should incorporate the specified syntax. We cannot dictate whether they do. * As in past IBIS modeling efforts, vendors may choose to provide a mapping mechanism to allow proprietary models to run in their systems, in order to support their customers. * A good example of this would be EDA vendor support for HAL 9000 IBIS-AMI models that use features that are proprietary and therefore not-portable. Each EDA vendor then chooses (or does not choose) to provide a custom portability design kit. * When the model maker creates proprietary models with parameter names and formats to support new flow or result altering functionality. That new functionality is inherently non-portable. Translation or mapping cannot necessarily be used to provide the necessary functions. * In this case, we can say that the original model is proprietary, and document that fact so that end-users and other EDA vendors are not surprised by the functionality, and are informed that the functionality will only perform as expected in specific tools. * Because these flow/result altering model functions have deep architectural implications at the EDA and model making levels, it should be strongly encouraged that the model makers come to the IBIS committee as soon as possible, to work towards an agreed upon specification. * If a specification is agreed upon, it makes sense for the original model makers to revise their models to meet the final form of the specification, and all future models using these functions to code to the specification. * It is exactly this class of proprietary model problem that the Out/InOut Bird seeks to highlight and avoid as much as is possible. If we all can agree on several points, I believe the committee process will become smoother and faster: * Portability * across platforms is good, as it allows for rapid market acceptance. * Generality * of constructs is good, as it allows for rapid portable feature enhancement. * Collaboration * on specification allows for a result that is greater than the sum of it's parts. Peace out Scott Scott McMorrow Teraspeed Consulting Group LLC 121 North River Drive Narragansett, RI 02882 (401) 284-1827 Business (401) 284-1840 Fax http://www.teraspeed.com Teraspeed(r) is the registered service mark of Teraspeed Consulting Group LLC