[ibis-macro] Re: Truth table taken to the next level
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Wed, 28 Apr 2010 10:32:06 -0700
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
Other related posts:
