[ibis-macro] Re: IBIS-AMI Model Portability
- From: <colin_warwick@xxxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 2 May 2011 14:14:52 -0600
Hi Scott,
Sorry, my previous message wasn't clear. I think we're actually 99.9% in
agreement.
When I said "Why bother?' I was not saying "why bother with advanced features?"
nor was I saying "why bother modeling advanced features?" Clearly, both
advanced features and modeling advanced features are very important.
No, what I was referring to was the thought earlier in this thread namely:
If an model contains proprietary extensions it is, by this definition,
non-compliant because it is deliberately engineered to give a radically
different answer (when run on a simulator with the matching proprietary
capability) than a model without the extension. Why bother adding the extension
otherwise? Sure, the model might run in a simulator without the matching
proprietary capability, but clearly it will then give the wrong answer, which
is worse than not running at all.
In other words "why bother adding the extension otherwise?" is a roundabout way
of claiming "Proprietary extensions are always significant and cannot be
omitted because if someone took the trouble to add them to the model and the
target simulator they must be essential to the task at hand and not merely
nice-to-haves"
Make sense?
-- Colin
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Scott McMorrow
Sent: Monday, May 02, 2011 11:31 AM
To: ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: IBIS-AMI Model Portability
Colin
"why bother" ... because the silicon vendor obviously wants to push the
state-of-the art and supply full functionality backchannel models to some of
it's customers who use a particular EDA tool. Makes perfect sense to me,
especially if there are lots of $$$ on the line.
If it were me, I'd take the hit to produce a non-standard proprietary model to
support a particular customer, and then work with the IBIS macro committee to
produce spec that includes the functionality, knowing full well that the model
would not work with full functionality in other EDA tools, and that it would
likely require modifications to the model and the target simulator when the
approved specification is released.
I'm not sure why you question this, Colin. This is not a theoretical concept.
A silicon vendor has done this. I just want to be sure that when vendors
provide these sorts of models that what is and what is not portable is
documented. Whether it "makes sense" is not my concern, insofar as a
non-portable model feature is concerned. What is of my concern, is that we
steer model makers towards bringing these features to the committee as soon as
possible, collaborating in good faith, and that the committee work towards
generalizing these features to reduce future model and spec "spin", thereby
allowing fully portable models.
Scott
* 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.
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
On 5/2/2011 10:29 AM,
colin_warwick@xxxxxxxxxxx<mailto:colin_warwick@xxxxxxxxxxx> wrote:
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>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow
Sent: Monday, May 02, 2011 9:41 AM
To: ibis-macro@xxxxxxxxxxxxx<mailto: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:
