Hi Arpad,
I am not sure what you are trying to get to. Your mention that IBIS-AMI could
be a ‘flexible modeling language’ points out that you are trying to make AMI
what it is not. IBIS-AMI is an API which allows model makers to describe the
behavior of their devices. It is not competing with Matlab, or C, or any other
general purpose ‘flexible modeling language’. It is a black box specification
where – if you want – you can use Matlab/Fortran/C or Verilog/VHDL to describe
whatever you want to describe – as long as it conforms to the C API described
in the IBIS specification. There are certain rules put in place to make it all
work and also so we can have the luxury of interoperability. But all of this
has been said before….
There may be issues with the analog portion, quality of the models or the AMI
flow or mixing ‘Statistical’ and ‘Time Domain’ models – but certainly – this is
not a methodology on the decline. Your reference of ‘starting to choke’ is very
premature and misplaced. At least that’s not a message one gets from the 20 or
so papers that mention or used IBIS-AMI methodology at this year’s DesignCon.
Also - taking your analogy of the car a little further – these are exactly the
rules that some states put in place and I believe these rules are put in place
to keep new drivers stay out of trouble – while going from point A to point B
in a more convenient, faster way. When they ignore these rules – bad things do
happen.
Thanks,
Ambrish.
From: ibis-bounce@xxxxxxxxxxxxx [mailto:ibis-bounce@xxxxxxxxxxxxx] On Behalf Of
Muranyi, Arpad
Sent: Thursday, June 11, 2015 11:44 PM
To: ibis@xxxxxxxxxxxxx
Subject: [ibis] Re: Flexibility of a specification
Walter,
You hit the nail on its head! And what you say is exactly what our
problem is, and what the IBIS (or any) spec should NOT do (at least
not on this level).
Regarding: “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.”
The problem in legacy IBIS is that it defines one structure and one
structure alone, 7 terminals, period. It only gives one and only one
way for describing the terminal voltages and currents of this structure
the I-V table. Any deviation in a real device from what this structure
can describe is a lost case. Consider the way [Composite Current] is
defined. It has no provisions to handle independent pre-driver and
output stage currents, the assumption is that these two blocks are
powered by the same supply rail and the total current of them can be
observed through one terminal. This is not always possible…
Does SPICE do this? No. You can define your structure the way you
want it and also its terminal voltages and currents (almost) any
whichever way you want it. That’s the big difference.
[External Circuit] was a major step away from this rigidity, because it
allows any number of terminals, and it allows any whichever way for the
model maker to define its terminal voltages and currents.
Regarding: “AMI is a spec describing the inputs and outputs of DLLs”,
unfortunately AMI not only does that, but it also defines what exactly
the footprint of these functions can be (and nothing else), what exactly
the inputs and outputs of these functions represent, and also in what
exact order these functions must be executed by the EDA tool. There is
a lot of fixed stuff in these definitions, which really is not for a
specification to define. This is like giving you a car and telling you
where you can go with it, what time you have to come and go, and who or
what you are allowed to have in the car...
Regarding: “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”
your usage of “language” here is in a different context from the way I
used it in my emails. I was not referring to whether the DLL should be
written in C++, Fortran, or what have you. I was referring to the
“language” of the IBIS specification, as if IBIS was a modeling language.
Maybe I used the word incorrectly in this sense, but please try to
understand what I am trying to say.
Thanks,
Arpad
==========================================================================
From: Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Thursday, June 11, 2015 9:09 PM
To: Muranyi, Arpad; ibis@xxxxxxxxxxxxx<mailto:ibis@xxxxxxxxxxxxx>
Subject: RE: [ibis] Re: Flexibility of a specification
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>
[mailto:ibis-bounce@xxxxxxxxxxxxx] On Behalf Of Muranyi, Arpad
Sent: Thursday, June 11, 2015 8:37 PM
To: ibis@xxxxxxxxxxxxx<mailto: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
