[ibis-macro] Re: IBIS-AMI Model Portability
- From: "Todd Westerhoff" <twesterh@xxxxxxxxxx>
- To: <scott@xxxxxxxxxxxxx>, "'Gregory R Edlund'" <gedlund@xxxxxxxxxx>
- Date: Mon, 2 May 2011 13:52:12 -0400 (EDT)
Scott & Greg,
To take this one step further, it’s possible today to ensure that a .dll
meets the IBIS-AMI Applications Programming Interface and passes data into /
out of the model as documented. That’s what the IBIS-AMI test benches do,
and both SiSoft and Cadence offer one. Each EDA company maintains their
public test bench to ensure that if a .dll works in their published tester,
it will work in their commercial EDA tool as well.
When the IBIS-AMI specification was first published, we expected that
ensuring proper “black box” behavior of .dll’s would be our biggest problem
(thus, the testers). In actual practice, we’ve spent far more time debating
what gets put in .ibs and .ami files, and what analysis flow the simulator
uses.
From a practical standpoint, I think the testers haven’t been enough,
because most users don’t seem to know they exist or what they’re meant to be
used for. So .. a plug fest, or baseline examples, or anything else that
lets the end-user establish that this model in that simulator duplicates
this reference result under those conditions … would be a good thing.
Todd.
________________________
Todd Westerhoff
VP, Software Products
SiSoft
6 Clock Tower Place, Suite 250
Maynard, MA 01754
(978) 461-0449 x24
twesterh@xxxxxxxxxx
www.sisoft.com
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow
Sent: Monday, May 02, 2011 12:53 PM
To: Gregory R Edlund
Cc: ibis-macro@xxxxxxxxxxxxx; ibis-macro-bounce@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: IBIS-AMI Model Portability
Greg
Yes, you do understand me. If the same standard/portable models create
different results in different tools, then we have a problem with either the
specification or the tools. As IBIS-AMI becomes more mature, it would make
sense to have a "plug-fest" where portability of results is tested.
I'm not advocating this right now, but it is a useful future possibility.
The goal of the committee should still be - That all simulators obtain the
same result based on knowledge obtained on how to process the parameters
from approved IBIS specifications and BIRDS. Just like the goal of PCIE Gen
3 is that all controllers and devices that are manufactured to that
specification should inter-operate.
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 5/2/2011 11:55 AM, Gregory R Edlund wrote:
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
Inactive hide details for Scott McMorrow ---04/30/201111:57:16 AM---Todd I'd
disagree with your assertion: "
... that Model_SScott McMorrow ---04/30/2011 11:57:16 AM---Todd I'd disagree
with your assertion: " ... that Model_Specific/Info
From: Scott McMorrow <mailto:scott@xxxxxxxxxxxxx> <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/> 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:
