[IBIS] IBIS-AMI Model Portability

Colin,

Thanks for your thoughts on the subject. I've been pondering the subject
as well and have something I'd like to propose for discussion.

Isn't the main issue here one of model portability between different EDA
tools? In particular, the ability of model makers, EDA vendors &
end-users to understand the likelihood that a particular IBIS-AMI model
will run in a particular EDA tool? It seems to be that "Compliant" is a
really broad term that can encompass everything from whether a model's
simulated output fits within a protocol's allowed jitter spec to whether
the model uses an agreed upon convention for documenting the analysis
modes the model supports. We need to care about all those things, but I'd
like to start with a way to assert whether a particular model will run in
a particular tool or not.

If I use a singular term (like Compliant or Compliant By Any Other Name),
the world is black and white - the model's either Compliant or it isn't.
That would work In a perfect world, but in practice, models come in black,
white and shades of grey. For sake of argument, I'll propose a
portability scale where 3 is the best (white), and 0 is the worst (black).
Let's assume the scale means the following:

`

0 (black) - The model has no portability. It's either completely
proprietary or uses features that haven't been publicly defined, such that
there's no chance of running it in multiple tools.

1 The model has limited portability. It uses
features that have been proposed for standardization, but that have not
been approved yet. One or more EDA tools may support it, but both the
model and the EDA tools that support it may need to change as the standard
evolves.

2 The model has theoretical portability. It uses a
combination of features that are part of the published standard and
features that have been approved for inclusion in future versions of the
standard. There's a chance that those new features will get changed as
they get incorporated into an updated standard, but the risk is considered
low. The model and EDA tools that support it may need to change to
support future versions of the standard, but probably not.

3 (white) - The model is completely portable. It uses only features
that are part of the published standard, and if it doesn't work in a given
EDA tool, it's most likely the EDA vendor's problem.

Would a rating scheme like that help? It seems to me the issue we're
grappling with is not black and white compliance, but risk assessment in a
practical sense.

I'm happy to discuss any variation on this theme that we can all agree on.

What do you think?

Todd.

________________________

Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@sisoft.com
www.sisoft.com

From: ibis-macro-bounce@freelists.org
[mailto:ibis-macro-bounce@freelists.org] On Behalf Of
colin_warwick@agilent.com
Sent: Thursday, April 28, 2011 11:43 AM
To: Arpad_Muranyi@mentor.com; ibis-macro@freelists.org; ibis@eda.org
Subject: [ibis-macro] Re: Minutes from the 26 Apr 2011 ibis-atm meeting
Proposed

Hi All,

It seems to me that the purpose of a standard is to promote the creation
of portable models. Why go to all the trouble of a long series of tense
committee meetings between competitors otherwise? Portability comes at a
price and that price is that it takes longer to incorporate innovation.

The definition of a portable model isn't just that it is syntactically
compliant with the standard, it must also be semantically compliant in
that it should give the same answer (within some acceptable accuracy) on
all compliant simulators.

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.

It doesn't matter whether the proprietary extensions are documented or
undocumented by the originator, nor whether they are proposed as a BIRD or
not, nor whether they have technical flaws or not: they are still outside
of the ratified standard, therefore controlled only by the author (who
could change it at will to match their latest simulator release), and
therefore models that use it are de facto non-portable.

I have no objections to proprietary extensions. They have the advantage
that innovation can be included quickly, but the disadvantage is that
models that include them are non-portable.

So my point (and I do have one) is that models with proprietary extensions
should not be labeled "compliant." That label should be reserved for
portable models that are both syntactically and semantically compliant
with the ratified standard of the time.

My $0.02

-- Colin

This is a retitled thread, the rest of the original thread has been
removed to reduce bandwidth on the reflector .

<snip>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
--------------------------------------------------------------------
|For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org
|with the appropriate command message(s) in the body:
|
|  help
|  subscribe   ibis       <optional e-mail address, if different>
|  subscribe   ibis-users <optional e-mail address, if different>
|  unsubscribe ibis       <optional e-mail address, if different>
|  unsubscribe ibis-users <optional e-mail address, if different>
|
|or e-mail a request to ibis-request@eda-stds.org.
|
|IBIS reflector archives exist under:
|
|  http://www.eda-stds.org/pub/ibis/email_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/users_archive/ Recent
|  http://www.eda-stds.org/pub/ibis/email/         E-mail since 1993