[ibis-macro] Re: IBIS-AMI Model Portability
- From: <colin_warwick@xxxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 2 May 2011 08:29:50 -0600
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
Other related posts:
