Arpad,
First, there are very flexible modeling languages out there (e.g. MatLab, C
numerical run time libraries). The point is, whatever language you use to
model an I/O buffer, you still need to define the interface to the model,
what are its input and what are its outputs. AMI is not a modeling language,
it simply defines the inputs and the outputs of a model.
Legacy IBIS is a spec for describing the current at a pad vs the voltage at
the pad and the voltages applied to the rails as a bunch of IV and VT
tables. External model is a spec for describing the ports of I/O buffer
models written in Berkley SPICE, IBIS-ISS, Verilog, VHDL. AMI is a spec
describing the inputs and outputs of DLLs that represent the amplitude
driving a linear amplifier in a Tx (Output) and the processing that an Rx
buffer does to convert the waveform at its input to a signal that can be
sampled at a latch.
So the question is not what language the user want to program the buffer
model, but what are the inputs and the outputs of a buffer model.
As soon as we have a new kind of model that has hologram inputs and outputs,
Kumar and I will argue about how they get transformed when they get beamed
up to the IBIS Starship.
Walter
From: ibis-bounce@xxxxxxxxxxxxx [mailto:ibis-bounce@xxxxxxxxxxxxx] On Behalf
Of Muranyi, Arpad
Sent: Thursday, June 11, 2015 8:37 PM
To: ibis@xxxxxxxxxxxxx
Subject: [ibis] Re: Flexibility of a specification
Walter,
Sorry for periodically going back to the thoughts that started this
thread (which is still in the subject line), but this response and
your clash with Kumar is a perfect candidate for another comment
along those lines.
Matlab, StatEye and COM was mentioned in the recent messages and it
was pointed out that they all suffer from the same problems Scott
raised about the LTI assumptions. It was kind of implied that
IBIS-AMI is just as good (or bad) as these other tools.
I would like to point out that it is StatEye, not Matlab that has the
problem here. Matlab is a programming/modeling language that I would
consider “flexible”. The model maker is not limited to write LTI
assumption based models or simulators in Matlab. The capability
for non-LTI work is all there in Matlab.
If IBIS-AMI would be a similar, flexible modeling language, you and
Kumar wouldn’t have to argue over Tx optimization, and we wouldn’t
have to change the spec every time we learn something new about
signal processing and SERDES design, or every time an IC vendor
comes out with a more sophisticated device, etc…
Did they have to change Matlab when someone decided to use it for
StatEye? Are they going to have to change Matlab when someone
decides to write a “Next Generation StatEye” that can handle
non-LTI effects?
No. And that’s my point. If we had a well written, flexible
modeling language, we wouldn’t have to change the spec as much
as have to now. IBIS suffered from this problem since its beginnings.
We were constantly lagging behind buffer design innovations. By
the time we got something into the spec, IC vendors were on to the
next generation buffers and we were still behind. IBIS was almost
dead around the time AMI was added to it. AMI gave it some new
life, but I see history repeating itself in AMI too. AMI did NOT
solve the rigidity problem of the spec, and we are starting to
choke from it again within the AMI feature set.
I am not harping on this because I find it pleasurable. I want to
raise awareness to this problem, and I hope that sooner than later
we will do something about it…
Thanks,
Arpad
======================================================================
From: ibis-bounce@xxxxxxxxxxxxx <mailto:ibis-bounce@xxxxxxxxxxxxx>
[mailto:ibis-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Thursday, June 11, 2015 5:26 PM
To: Scott McMorrow
Cc: ibis@xxxxxxxxxxxxx <mailto:ibis@xxxxxxxxxxxxx>
Subject: [ibis] Re: FW: Re: Flexibility of a specification
Scott,
Let’s put AMI modeling aside, and talk about what people are doing with
MatLab, Stat-Eye, or 802.3bj COM. They all need the same Impulse Response
(or equivalent Pulse Response) of the channel. So they all suffer from the
same problem of generating an Impulse Response of the channel. AMI modeling
is just Stat-Eye and MatLab with IP protection, interoperable models and
portable models. So the LTI assumption and the limitations it introduces for
short, low loss channels has been a limitation the industry has always had.
And to your point, the comparison of various EDA tools should be done using
20, 30 and 35 dB channels. We do these comparisons all of the time.
Walter
