Ken, I couldn't disagree with you more, but then you already knew that. This effort isn't EDA-centric at all, and never was, in my opinion. The focus has always been squarely on allowing the systems designer to use IBIS-AMI models and simulation tools to make critical design decisions. Statistical simulation lets users run many simulations quickly to identify which cases have the best chance of success. Time-domain simulation provides the detailed modeling of adaptive equalization and clock recovery needed to sign-off a design into manufacturing. That's been the vision since late 2006. IBIS-AMI has always supported both simulation modes. The first reference model and toolkit SiSoft released in August 2007 demonstrated how Init and Getwave can perform the equalization needed to support both Statistical and Time-Domain simulation. Multiple semiconductor vendors have already released IBIS-AMI models that support both Statistical and Time-Domain simulation (Init_Returns_Impulse = True, Getwave_Exists = True, Use_Init_Output = False) and the systems companies we're working with are asking their semiconductor suppliers to release more. Those same systems companies are asking semiconductor companies whose IBIS-AMI models don't support both simulation modes to upgrade their models. The system designers clearly see the benefit. Commercial models and EDA tools that support both simulation modes have been in the marketplace for over 2 years. This discussion is about properly documenting the capabilities and flows that already exist, not going back to a "simpler flow". Customers simply aren't going to abandon capabilities they find useful and productive. Scott was absolutely right; model makers want flexibility in creating a model and documenting how it should be used, and the simulator control parameters we've been discussing give them exactly that capability. The questions you've listed below amount to a model maker asking for guidance as to how they should best represent their IP's equalization and clock recovery behavior. There's no doubt that we can provide clear guidance to that model maker for the flows we've been discussing. 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 Ken Willis Sent: Wednesday, April 28, 2010 11:09 AM To: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: Truth table taken to the next level Hi Arpad, My apologies for missing the meeting yesterday, I just returned from vacation and was digging out. I am concerned that we are going in entirely the wrong direction with this, in that it is becoming far too EDA-centric and not IP supplier-centric enough. And I think the latter is what we need to focus on if we are ever to have a robust pool of Serdes models available for the SI engineering community to use. I have spoken with a lot of Serdes IP suppliers, and have never heard any mention of supporting statistical or LTI TD or non-LTI TD or partial statistical or full non-LTI TD or any other specific kind of analysis. What I hear is things much more like this: - What IBIS-AMI API do I need to use for my Serdes Tx / Rx? I want to use the most straightforward approach to model my filter. - Does the filtering in my Serdes IO do a one-time adaptation to my channel? If it does I will use the modified impulse response approach, since that is simplest. - Does my filtering do real-time dynamic kind of adaptation? If it does, I will need to use the GetWave approach and process waveforms directly. This is admittedly a little over-simplified, but I think is basically on target. I think we would do much better to think more along these lines rather than add all the complexity I see in these tables below. To be successful, I think we need to keep this as simple as possible, and enable models to be developed. I would even go as far as to say that the most practical approach for a given Serdes IO would be to use either the impulse response or GetWave API, but not both together. I would be interested to hear opinions on these ideas from the people on this list. Thanks, Ken Willis Sigrity, Inc. 860-871-7070 kwillis@xxxxxxxxxxx _____ From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad Sent: Wednesday, April 28, 2010 1:57 AM To: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Truth table taken to the next level Dear AMI experts, I cleaned up the spreadsheet with the truth table that we discussed in our ATM meeting today. It looks like this now: Picture (Device Independent Bitmap) I hope I got it right this time. The next thing I would like to do is to extend this table and spell out how these conditions can be applied to Tx and Rx independently. In other words, I don't believe that our intent was to require these Booleans to be the same for both Tx and Rx. But how many combinations are valid? We have four (4) combinations per buffer, and we have two buffers, which could theoretically allow 4^2 = 16 total possibilities. Are they all valid? Picture (Device Independent Bitmap) Thanks, Arpad ============================================================