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.
o 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.
o 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.
o 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.
o 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.
o 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
o across platforms is good, as it allows for rapid market
acceptance.
* Generality
o of constructs is good, as it allows for rapid portable
feature enhancement.
* Collaboration
o 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® is the registered service mark of
Teraspeed Consulting Group LLC
