Bob,
You are precisely correct. Cadence and SiSoft have already published AMI
source code on the IBIS Web Site. David Banas and SPISIM may also be a
source of such models.
We should evaluate what we have and ask for contributions for such exemplar
code. The hard pard of AMI model development is optimizing taps and
determining an Equalization IR. This prototype AMI_Init code could have a
hardcoded Equalization IR, convolve it with the input IR, store it in the
AMI_memory that is available in the AMI_GetWave, and have the AMI_GetWave
use an overlap and save algorithm to convolve the Equalization IR with the
input Get_Wave.
There is nothing proprietary in this source code. Adding a parameter tree
parser for the input would be helpful.
This can be a free item, or we can hire someone to do and support it, and
charge for the software like we do the Parser.
Walter
Walter Katz
wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308
Mobile 303.335-6156
From: Bob Miller (APD) [mailto:bob.miller@xxxxxxxxxxxx]
Sent: Wednesday, May 10, 2017 11:29 AM
To: Walter Katz <wkatz@xxxxxxxxxx>
Cc: IBIS-ATM <ibis-macro@xxxxxxxxxxxxx>
Subject: Re: [ibis-macro] Summary of discussion about BIRD 166.2
Walter --
Thanks for a concise summary (at least from your vantage point).
regarding #2 on "what IBIS should do" -- We should possibly (re-) post a
clear prototypical AMI_GetWave for init-only models.
This begs the question of what needs to be retained in the AMI_memory from
AMI_Init to equip this prototypical AMI_GetWave. it is probably:
* AFE impulse response
* DFE impulse response (or a normalized DFE gain table).
* simulation parameters such as sample_interval, bit_time, etc.
Of course other architecture-specific things may complicate this, but I
think if the AMI_Init response is valid to the point that the model maker
doesn't see the need for AMI_GetWave, the architecture-specific things must
be largely unnecessary.
The interesting thing is I think one can view the Keysight enhancement as
sending exactly this data to the EDA tool so the EDA tool can implement the
model's AMI_GetWave by proxy. Indeed, in my mind it begs the question of if
one can view (and even reinterpret) the BIRD as an AMI_GetWave generator
that EDA tools provide to provide for "lazy" modelers. If so, can we just
publish the proxy AMI_GetWave and be done with it?
Regards,
Bob
On Wed, May 10, 2017 at 6:15 AM, Walter Katz <wkatz@xxxxxxxxxx
<mailto:wkatz@xxxxxxxxxx> > wrote:
All,
Let me summarize the discussion we had on May 9 about BIRD 166.2 by
describing five scenarios, and then some concluding remarks.
Scenario 1, all four AMI models in the Redriver flow (Tx1, Rx1, Tx2, Rx2)
are Init Only models.
The current flow in IBIS 6.1 is flawed because the Rx2 AMI_Init function
does not receive the complete IR input to properly determine its
equalization.
There is unanimous agreement that BIRD 166.2 fixes this for statistical
simulations.
Scenario 2, all four AMI models in the Redriver flow (Tx1, Rx1, Tx2, Rx2)
are Dual models.
The current flow in IBIS 6.1 is flawed because the Rx2 AMI_Init function
does not receive the complete IR input to properly determine its
equalization.
There is unanimous agreement that BIRD 166.2 fixes this for both statistical
and time domain simulations.
Scenario 3, the Tx1 and Rx1 AMI models are Dual Models and the Tx and Rx2)
are Init Only models.
The current flow in IBIS 6.1 is flawed because the Rx2 AMI_Init function
does not receive the complete IR input to properly determine its
equalization.
There is unanimous agreement that BIRD 166.2 fixes the statistical flow, but
the time domain flow remains problematic.
Scenario 4, all four AMI models in the Redriver flow (Tx1, Rx1, Tx2, Rx2)
are a combination of Init Only and Dual models.
The current flow in IBIS 6.1 is flawed because the Rx2 AMI_Init function
does not receive the complete IR input to properly determine its
equalization.
There is unanimous agreement that BIRD 166.2 fixes the statistical flow, but
the time domain flow remains problematic.
Scenario 5, one or more of the four AMI models in the Redriver flow (Tx1,
Rx1, Tx2, Rx2) are GetWave Only models.
There is no valid statistical flow.
The conclusion is that BIRD 166.2 is the correct statistical flow when all
four AMI models in the Redriver flow (Tx1, Rx1, Tx2, Rx2) are a combination
of Init Only and Dual models, and is the correct time domain flow when all
four models are Dual Models.
What I believe IBIS should do is:
1. Approve BIRD 166.2
2. Recommend that all four AMI models in the Redriver flow (Tx1, Rx1, Tx2,
Rx2) are Dual Models in order to support Time Domain flow.
a. Note that any Init Only AMI model can easily be upgraded by the model
maker to a Dual Model.
3. Enhance IBIS AMI by adding additional IR outputs to the AMI_Init
function
that contain the linear (CTLE) and non-linear (DFE) equalization of the
model. (Keysight AMI_Init Enhancement)
Which leads to the following questions:
1. Is the Keysight AMI_Init Enhancement necessary if all AMI Models are
Dual Models?
2. Is it easier for a model maker to implement the Keysight AMI_Init
Enhancement instead of making Dual Models?
3. If a model maker is too lazy to make a Dual Model, will he be too lazy
to
implement the Keysight AMI_Init Enhancement?
4. Will the EDA tools that are used by model makers implement the Keysight
AMI_Init Enhancement?
Note that the Keysight AMI_Init Enhancement does not address the problem of
AMI_GetWave only models.
Walter
Walter Katz
wkatz@xxxxxxxxxx <mailto:wkatz@xxxxxxxxxx>
Phone 303.449-2308 <tel:(303)%20449-2308>
Mobile 303.335-6156 <tel:(303)%20335-6156>
