[ibis-macro] Re: IBIS-AMI Model Portability
- From: <colin_warwick@xxxxxxxxxxx>
- To: <twesterh@xxxxxxxxxx>, <ibis-macro@xxxxxxxxxxxxx>, <ibis@xxxxxxx>
- Date: Fri, 29 Apr 2011 10:13:01 -0600
Hi Todd,
Thanks!
I think it's a step in the right direction. But I'm not sure portability is a
scalar quantity, and not sure who would be the Motion Picture Association of
America-style organization that polices the rating scheme.
How about this instead:
"Here is my model and I claim it runs correctly in the following EDA tools: A,
B, C, D. Here is my verification report for Tool A. Here is my verification
report for Tool B. (etc.) It may or may not run in other tools but I haven't
checked. Ask the vendor."
Thoughts?
-- Colin
From: Todd Westerhoff [mailto:twesterh@xxxxxxxxxx]
Sent: Friday, April 29, 2011 10:56 AM
To: WARWICK,COLIN (A-Americas,ex1); ibis-macro@xxxxxxxxxxxxx; ibis@xxxxxxx
Subject: 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@xxxxxxxxxx<mailto:twesterh@xxxxxxxxxx>
www.sisoft.com<http://www.sisoft.com>
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of colin_warwick@xxxxxxxxxxx
Sent: Thursday, April 28, 2011 11:43 AM
To: Arpad_Muranyi@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx; ibis@xxxxxxx
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>
Other related posts:
