[ibis-macro] Re: IBIS-AMI Model Portability
- From: Scott McMorrow <scott@xxxxxxxxxxxxx>
- To: ibis-macro@xxxxxxxxxxxxx
- Date: Fri, 29 Apr 2011 11:43:46 -0400
Todd
I'd use the following rating
0 - no portability
1 - BIRD approved and referred from macro committee to full forum
2 - BIRD approved by full forum
3 - BIRD integrated into next version of IBIS specification
There is too much uncertainty in what happens when a BIRD proposal is
initially introduced. At that point I'd say there is no portability.
Usage of the feature is still proprietary Portability is only a
possibility when more than one EDA vendor is willing to commit software
engineering resources to add the feature. It's unlikely that this would
occur prior to macro committee approval.
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
On 4/29/2011 10:56 AM, Todd Westerhoff wrote:
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.
1The 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.
2The 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:
