[ibis-macro] Re: IBIS-AMI Model Portability
- From: Gregory R Edlund <gedlund@xxxxxxxxxx>
- To: scott@xxxxxxxxxxxxx
- Date: Mon, 2 May 2011 10:55:23 -0500
Scott,
You said, "I contend that the following is a good operational definition of
work - That all simulators obtain the same result based on knowledge
obtained on how to process the parameter from approved IBIS specifications
and BIRDS."
It sounds like you're suggesting we adopt a "plug fest" approach to
establishing portability of IBIS AMI models. Users would love this. Model
makers would see it as a hoop to jump through. EDA vendors might be
indifferent (I don't know).
How would this work? Would we have an on-line plug fest where a designated
set of people run new models through a designated set of simulations
designed to shake out the model? And if we see a discrepancy, how do we
determine if the source lies within the model or the simulator?
Sounds like a valuable approach, but one that has a lot of far-reaching
implications.
Did I understand you?
Greg Edlund
Senior Engineer
Signal Integrity and System Timing
IBM Systems & Technology Group
3605 Hwy. 52 N Bldg 050-3
Rochester, MN 55901
From: Scott McMorrow <scott@xxxxxxxxxxxxx>
To: ibis-macro@xxxxxxxxxxxxx
Date: 04/30/2011 11:57 AM
Subject: [ibis-macro] Re: IBIS-AMI Model Portability
Sent by: ibis-macro-bounce@xxxxxxxxxxxxx
Todd
I'd disagree with your assertion: " ... that Model_Specific/Info
parameters would work without the need for a model “compatibility mode”.
It depends on how you define work. If "work" is defined to be that the
results are identical in all simulators which use the model, then in no
case does the parameter work, unless the meaning of the parameter is
well-documented and agreed upon. This is the purpose of a specification.
Guessing correctly does not count. If it ain't in the specification, in my
option, that specific function is not portable. The remainder of the model
may be compatible and portable, which is a nice thing to have, but the
model specific part is not, and does not achieve the model maker's
intention. Other EDA vendors may choose to make a decision to support the
parameter through a custom process, but that doesn't change the fact that
the parameter is not portable, and does not "work" in a simulator that
adheres strictly to the IBIS specifications and BIRDS.
I contend that the following is a good operational definition of work -
"That all simulators obtain the same result based on knowledge obtained on
how to process the parameter from approved IBIS specifications and BIRDS."
I'd agree with regards to your portability rating, which is different than
your introductory statements. Your Rx_Noise parameter gets a portability
rating of 0. All other standard parameters and functions within the model
get a rating of 3.
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/30/2011 12:29 PM, Todd Westerhoff wrote:
3. If the EDA tool does not understand RX_Noise and has no
equivalent simulator-specific noise feature, then the data is simply
ignored, and the simulator proceeds as it would have if the model had
not included a RX_Noise parameter at all. Nothing wrong with that,
in our opinion.
Other related posts:
