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.