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] On Behalf Of
Walter Katz
Sent: Thursday, June 11, 2015 5:26 PM
To: Scott McMorrow
Cc: 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
