Ken, I second what Scott is saying, but in addition to that, regarding your comment "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." I would like to mention that these simulation types are a fact of life in the SERDES world whether we mention them or not. First, please note that these appear in the "comment" column of the truth table, which means that it is only mentioned for informational purposes. If people don't like to use this terminology, they don't have to even look at it. They can go by reading the various Boolean values of the AMI "flow control" parameters and decide what is the best solution for them based on those. But given the current AMI specification and the already established functions AMI_Init, and AMI_GetWave, the capabilities of running a pure LTI statistical simulation or a non-LTI TD simulation or a combination of the two are a given. The purpose of our work here is to eliminate the ambiguities and errors in the specification, and not to introduce new features or rewrite it from scratch. This truth table was created to spell out unambiguously what the intent and meaning of the current specification is, by enumerating the possible combinations of the existing functions and controls so we can make the existing spec clearer and eliminate the possibility for different interpretations (like the ones we heard in the meeting just yesterday). I am really glad we went through this truth table, because it brought various interpretations on the surface, which I wouldn't have imagined before. By the way, it is impossible to answer the first two questions you mentioned without first asking your customers to clarify what they mean. "...I want to use the most straightforward approach to model my filter." Do they want an eye generated by statistical algorithms (such as peak distortion analysis), or do they want an eye generated by a Time Domain simulation (where the filter is convolved with a stimulus pattern of some sort, like PRBS, with or without 8B/10B, etc...)? "...If it does I will use the modified impulse response approach, since that is simplest" Yes, this may be the simplest, but you can still use this approach in two different ways as described above (statistical or TD simulation) so "picking the simplest" doesn't tell me unambiguously what they want to do. Let me illustrate this situation with a made-up story: People are flocking to car dealers and tell them that they want to buy the simplest and most economical car. So the dealers asks them the question, what type of a car would they like to buy? The options are: - a small car with a small gasoline engine - a small car with a hybrid gas/electric engine - a small fully electric car (or plug-in hybrid) - a small natural gas / propane powered car but the customers say: We don't want to talk about any of these engines, just give us the simplest car. So the dealers sell a lot of small cars with the smallest gasoline engine and the customers go home happily with their new cars. In the meantime the dealers return all of their other car types to the factory because they think that they will never sell any of them, and the factory stops making them due to poor sales. Some time later customers start going back to the dealers. They say they want hybrid cars because people are getting cancer from the exhaust fumes the gasoline engines generate in the garage and hybrid cars are better because they only turn on the gasoline engine once they are on the road. The dealers reply: You should have been willing to understand the different types of engines the first time you came to buy the car. Now we can't offer you any of those, none of them are on the market any more. Yes, the dealer and the maker may have been way ahead of the customers, and the hybrid car may have been a lot more complicated than the simple gasoline engine car, but which one was a better solution? Arpad ======================================================================== = ________________________________ From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Scott McMorrow Sent: Wednesday, April 28, 2010 10:33 AM To: kwillis@xxxxxxxxxxx Cc: ibis-macro@xxxxxxxxxxxxx Subject: [ibis-macro] Re: Truth table taken to the next level Ken Having a number of modeling and simulation options available does not preclude a model developer from doing just exactly what you say - creating models that support the simplest of flows. As a designer, an architect and a model maker, I will always opt for maximum flexibility in the specification that supports current and future devices. Teraspeed Consulting will always support the maximum flexibility in the IBIS-AMI specification. regards, Scott Ken Willis wrote: 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