[ibis-macro] Re: Analog Buffer Modeling - A Summary
- From: "Muranyi, Arpad" <Arpad_Muranyi@xxxxxxxxxx>
- To: 'IBIS-ATM' <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 23 Jan 2012 23:21:22 +0000
I just realized after I pressed the "Send" button that
modeling multi-tap buffers is already possible with the
[External Model] *-AMS languages TODAY, so we don't even
have to wait for IBIS-BSS to become a reality for being
able to do that... But I know, the *-AMS languages are
another story of their own...
Thanks,
Arpad
=========================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx [mailto:ibis-macro-bounce@xxxxxxxxxxxxx]
On Behalf Of Muranyi, Arpad
Sent: Monday, January 23, 2012 5:10 PM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Analog Buffer Modeling - A Summary
Walter,
Here are my comments.
Your points #1-#6 are all true, but are not proof for needing
"canned models" in the IBIS spec for AMI purposes. Based on
#5 and #6, work can get done without canned models using the
more general IBIS-ISS modeling approach. What is the compelling
reason to add these canned models to the IBIS specification then?
I want to extend this thought a little further. We don't even
need IBIS-ISS to make an LTI buffer model that is equivalent
to your discrete (RC) version of the "canned model". Last
time I looked at that circuit, I didn't find anything in it
that couldn't be done with our legacy I-V and [Ramp] based
models (without even needing the [External Model] features).
(Remember, a two point I-V curve is a linear buffer model...)
What is the reason to need the discrete (RC) versions of the
canned analog models if legacy IBIS already has the ability
to describe everything they do?
The only canned models I see going beyond the abilities of
legacy IBIS are the Touchstone file based canned circuits,
because they provide the capability to describe the frequency
dependent C_comp behavior of the buffer which is not possible
with legacy IBIS. But the Touchtone file S-parameter approach
is available in the IBIS-ISS based proposals, so I still don't
see the need for the canned circuit approach in addition to
that.
Since you asked, here is one bad thing that could happen with
your canned model approach:
Your canned model is only "invokable" for IBIS-AMI purposes.
You assume that other than finding the [Algorithmic Model]
keyword, the rest of the .ibs file is pretty much not needed.
While that may be true from an AMI simulation perspective,
think about a user who would like to do a correlation study
between the AMI waveforms and a normal analog simulation. They
will not be able to do that because the canned analog model
is not available to the analog IBIS simulator.
The IBIS-ISS approach keeps the analog model available for the
analog engine of the IBIS simulator. The tool can use it for
normal simulations or for generating the impulse response for
the AMI models.
You may say, there is not much that the user can correlate without
being able to model the various taps in the analog buffer model.
While that is true, the user could still correlate waveforms
using the main tap only, but as we make advances with IBIS-BSS,
the modeling of multi-tap drivers may become possible later.
In addition to the above, we need to decide on the hierarchy of
IBIS in general. So far, we have an .ibs file with a [Package]
reference and a [Pin] list, which reference [Model]-s, which
reference [Algorithmic Model]-s and their associated parameter
(.ami) files. The canned model approach turns this somewhat
upside down, as it tries to reference the canned analog models
from the AMI parameter (.ami) file. So where is the "cockpit"
(or command center) of our IBIS world? Is it in the .ibs file
or the .ami file?
Currently, pg. 139 (the introduction to the AMI section) says:
| ...The "analog" portion of the channel is
| characterized by means of an impulse response leveraging the pre-existing
| IBIS standard for device models.
So taking analog modeling out of the .ibs file and giving
control over the analog device modes to the .ami file seems
to be a deviation even from our existing IBIS-AMI specification.
Don't take me wrong, I am not opposed to changes, I just want
to have a good reason for doing it, and once we decided that
we need to have a certain change, I would like to do it in
a way that is consistent with the rest of the specification...
Thanks,
Arpad
=================================================================
From: ibis-macro-bounce@xxxxxxxxxxxxx<mailto:ibis-macro-bounce@xxxxxxxxxxxxx>
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]<mailto:[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]>
On Behalf Of Walter Katz
Sent: Friday, January 20, 2012 7:06 AM
To: 'IBIS-ATM'
Subject: [ibis-macro] Re: Analog Buffer Modeling - A Summary
All,
I have not received any comments that disagree with the following statements,
other than objections to having the ability to have four canned models in
addition to allowing general purpose ISS Buffer subckts. I have no objection in
principle to adding the canned Tstonefile proposal in BIRD 144 (we can debate
some of the details). Why object to the 4 canned ISS subckts that I have
proposed. In summary:
1. They satisfy the needs of all SerDes standards that have been
approved, and all SerDes standards in development.
2. They accurately represent the LTI behavior of legacy IBIS models (IV
and VT tables).
3. They represent circuits that EDA tools can easily and efficiently
implement.
4. They make it easy for SerDes IC Vendors to accurately describe the
analog behavior of their models.
5. There is nothing that prevents SerDes IC Vendors from creating custom
ISS Buffer AMI subckts.
6. There is nothing that prevents IC Vendors from creating custom ISS
Buffer subckts for traditional single ended and differential buffers.
These are compelling arguments that IC Vendors and Users of IBIS AMI models
will support.
The argument that there will be a desire to add a plethora of new canned models
is specious.
No one has given an argument of what bad things can happen with the inclusion
of these canned models in the standard.
I hold these truths to be self-evident, please be prepared to voice your
objections at next week's IBIS-ATM meeting and the DesignCon IBIS Summit.
Walter
Other related posts:
