[ibis-macro] Re: IBIS-AMI Model Portability

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

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



Scott McMorrow ---04/30/2011 11:57:16 AM---Todd I'd disagree with your assertion: " ... that Model_Specific/Info

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.