[ibis-macro] Re: An AMI Overview
- From: "C. Kumar" <kumarchi@xxxxxxxxx>
- To: wkatz@xxxxxxxxxx, ibis-macro@xxxxxxxxxxxxx, fangyi_rao@xxxxxxxxxxx
- Date: Tue, 13 Oct 2009 09:17:13 -0700 (PDT)
my suggestion is to document the flows as two separate cases
1. cases with no txgetwave
in these cases the flow is relatively uncomplicated . tx_init/rx_init always
modifies the impulse response and the current flow will work. less complicated
flows will result in more robust/reliable models
2. flow when txgetwave exists
--- On Mon, 10/12/09, fangyi_rao@xxxxxxxxxxx <fangyi_rao@xxxxxxxxxxx> wrote:
From: fangyi_rao@xxxxxxxxxxx <fangyi_rao@xxxxxxxxxxx>
Subject: RE: [ibis-macro] Re: An AMI Overview
To: kumarchi@xxxxxxxxx, wkatz@xxxxxxxxxx, ibis-macro@xxxxxxxxxxxxx
Date: Monday, October 12, 2009, 10:15 PM
Hi, Kumar;
As Walter pointed out Rx Init does need a modified impulse from
Tx to prepare GetWave or to optimize taps for optimal performance. The problem
of
all these confusion and broken flows is that AMI is letting the Init function
provide
multiple functionalities including
Prepare for GetWave or optimize taps
Return approximate LTI model for statistical simulation
Return Tx/Rx EQ information
It is too much to put in one single function.
Fangyi
From: C. Kumar
[mailto:kumarchi@xxxxxxxxx]
Sent: Monday, October 12, 2009 6:54 PM
To: wkatz@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx; RAO,FANGYI (A-USA,ex1)
Subject: Re: [ibis-macro] Re: An AMI Overview
instead of knotting up all over the place, we have to
simplify the flow
i.e if a model has getwave , it cannot modify the impulse response
if the vendor wants to provide approximate models he has to provide separate
models containing just init,
any other method of prescribing both getwave and init will need to confusion
and broken models/flows
--- On Mon, 10/12/09, fangyi_rao@xxxxxxxxxxx <fangyi_rao@xxxxxxxxxxx>
wrote:
From: fangyi_rao@xxxxxxxxxxx <fangyi_rao@xxxxxxxxxxx>
Subject: [ibis-macro] Re: An AMI Overview
To: wkatz@xxxxxxxxxx, ibis-macro@xxxxxxxxxxxxx
Date: Monday, October 12, 2009, 8:34 PM
Hi,
Walter;
You
may not notice in my example the Rx Init returns h_AC*h_TEI +
h_REI instead of h_AC*h_TEI*h_REI. In this case the Tx portion can’t be
removed from the final impulse by deconvolution. We can’t recover h_REI by
deconvolution either. The flow will be broken if Tx has GetWave but Rx does
not.
Thanks,
Fangyi
From: Walter Katz
[mailto:wkatz@xxxxxxxxxx]
Sent: Monday, October 12, 2009 4:39 PM
To: RAO,FANGYI (A-USA,ex1); ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: An AMI Overview
Fangyi,
By
deconvolution ( http://en.wikipedia.org/wiki/Deconvolution ).
The input to Rx
Init is h_AC*h_TEI, the output of Rx Init is h_AC*h_TEI*h_REI.
Deconvolution takes the Fourier Transform of the input and output impulse
responses, then divides the coefficients of the two Fourier Transforms, and
then does an inverse Fourier Transform to get h_REI. We do this for this flow
because we have no other choice. That is why I am proposing to add to Rx Init
models the ability to just return h_REI.
Walter
Walter Katz
303.449-2308
Mobile 720.333-1107
wkatz@xxxxxxxxxx
www.sisoft.com
-----Original Message-----
From: fangyi_rao@xxxxxxxxxxx [mailto:fangyi_rao@xxxxxxxxxxx]
Sent: Monday, October 12, 2009 6:55 PM
To: wkatz@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: An AMI Overview
Hi, Walter;
Thanks for your explanation. Regarding point 2, I still think
if model vendors are allowed to modify impulse any way they want, then
following scenario will be broken.
Tx has GetWave.
Tx Init modifies h_AC and returns h_AC_Tx=h_AC*h_TEI
Rx does NOT have GetWave.
h_AC_Tx is passed into Rx Init.
Rx Init modified h_AC_Tx and returns h_AC_Tx_Rx= h_AC*h_TEI +
h_REI
Tx GetWave output is to be convolved with h_AC_Rx=h_AC +
h_REI, which is the combined impulse of channel and Rx.
Without knowing how Rx Init modifies the impulse, how can EDA
tools remove the h_TEI portion from h_AC_Tx_Rx to get h_AC_Rx?
Thanks,
Fangyi
From:
Walter Katz [mailto:wkatz@xxxxxxxxxx]
Sent: Monday, October 12, 2009 3:04 AM
To: RAO,FANGYI (A-USA,ex1); ibis-macro@xxxxxxxxxxxxx
Subject: RE: [ibis-macro] Re: An AMI Overview
Fangyi,
1. Even if a model is non-LTI,
it may have an LTI approximation. If the Init call returns an LTI
approximation, then the EDA tool can use “Statistical” methods to do very
fast analysis, realizing that the GetWave time domain simulation will still
need to be made to confirm the result. If the Init call does not return an
LTI approximation, then the EDA tool must use time domain methods only to
analyze the channel.
2. The current IBIS 5.0
specification has words like (section 2.1.6):
|
6. AMI_Init parses the configuration parameters, allocates dynamic
|
memory, places the address of the start of the dynamic memory in
|
the memory handle, computes the impulse response of the block and
|
passes the modified impulse response to the EDA tool. The new
| impulse
response is expected to represent the filtered response.
Since
returning an impulse response assumes LTI (or an LTI approximation), the
model maker can do this calculation any way he chooses. One way to do this
calculation convolution. We spent much time determining if we should use the
word convolution, concatenation, combination, and ended up with the word
modified. It would probably be worth adding a paragraph to the document that
explicitly says that whenever convolution is used, it is simply to represent
the result of the function to be preformed, and the model maker or EDA vendor
can use any mathematical method deemed appropriate for performance, accuracy
or other algorithmic reasons.
Walter
Walter Katz
303.449-2308
Mobile 720.333-1107
wkatz@xxxxxxxxxx
www.sisoft.com
-----Original Message-----
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx]On Behalf Of fangyi_rao@xxxxxxxxxxx
Sent: Sunday, October 11, 2009 8:22 PM
To: wkatz@xxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
Subject: [ibis-macro] Re: An AMI Overview
Hi, Walter;
Thanks for your clarification of AMI methodology. I’d like to
see the overview or the spec also states clearly about following two topics.
1. For
non-LTI models that have GetWave, how does AMI_Init enable model developers
to also support statistical simulation using LTI approximation?
2. Do
we explicitly assume the modified impulse returned by AMI_Init is the
CONVOLUTION between input impulse and the equalizer? I know at least one
model vendor would not be happy about this assumption because their modified
impulse is not from convolution.
Regards,
Fangyi
From: ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] On Behalf Of Walter Katz
Sent: Saturday, October 10, 2009 2:20 PM
To: IBIS-ATM
Subject: [ibis-macro] An AMI Overview
All,
We
have all been getting into the nuts and bolts of AMI. I think we need to step
back and understand what AMI is all about. The following has been said in
many ways in many places, but I think it is appropriate to review it at this
time. I do not know if this belongs in the IBIS AMI specification, but it
sure would be nice.
Walter
AMI
Overview
The
analysis of high speed (>4 Gbps) offers some simplifications and some
challenges. The simplifications arise from the fact the driver (Tx) final
stage output, and the receiver (Rx) input along with the interconnect between
them can be treated as Linear and Time Invariant (LTI) “Analog-Channel”. This
allows various mathematical techniques to be applied improving simulation
performance by orders of magnitude. The complication that has led to the
development of the AMI standard arises from the need for complex signal
processing in both the Tx before the final stage driver and particularly the
Rx after the Rx receiver. The good news is that the signal processing does
not interact with the Tx/Interconnect/Rx Analog-Channel. The signal
processing that is going on is considered important Intellectual Property
(IP) of the IC vendors, and this along with the need for simulating millions
of bits and the IP considerations led to the AMI standard.
A
SerDes-Channel consists of Tx signal processing, Analog-Channel and Rx signal
processing. The Tx AMI model represents the Tx signal processing, an impulse
response represents the Analog-Channel, and the Rx AMI model represents the
Rx signal processing.
The
Analog-Channel is represented as an impulse response hAC(t). It is the
differential mode impulse response of the interconnects between the Tx and
the Rx and includes the reactive load (impedance) of the Tx final stage
driver and the Rx receiver. This impulse response can be created using many
mathematical techniques, including, but not limited to simulation and TDR
measurement. Traditional IBIS does not model differential LTI buffers, this
will be addressed when I introduce new AMI reserved parameters. This is also
related to the topic of Vladimir’s presentation this Tuesday.
The
Tx AMI model and Rx AMI model may themselves be either LTI or non-LTI. If
they are LTI they can be represented accurately by an impulse response. If
they are not LTI, they can be approximated by an impulse response. AMI models
are delivered as executable code in the form of a Shared Object (SO) or a
Dynamically Linked Library (DLL), and an .ami ASCII file. All AMI DLL’s
have an AMI_Init entry, and an AMI_Close entry. This is all that is required
if the model is LTI. If a model is non-LTI then is must also have an
AMI_GetWave. If a model does have an AMI_GetWave then the model make is
telling the EDA tool that the model is non-LTI and that using the just
impulse response from the AMI_Init is not deemed sufficient to accurately
model the channel.
The
.ami file tells the EDA tool if the model has an AMI_GetWave entry, and
sufficient information to configure the model, and to analyze the results
that the model generates.
When
a model is LTI it does not need a GetWave entry. When LTI, the only
information that need be abstracted from the model is the impulse response of
the models equalization. The input to the Tx AMI_Init function is the impulse
response of the channel. The input to the Rx AMI_Init function is the impulse
response of the channel combined with the impulse response of the Tx
equalization obtained from the call to Tx AMI_Init.
When
a model is non-LTI (or more importantly, the IC Vendor believes that the
non-LTI behavior is important) then it does require an AMI_GetWave entry. The
AMI_Init entry is used to return to the EDA tool an approximate impulse
response of the models equalization, and to pass on initialization
information to be used by the AMI_GetWave entry. The AMI_GetWave entry is
then called repeatedly with sequential blocks of waveforms. The waveforms are
that are input to Tx AMI_GetWave indicate the transition times of the digital
stimulus input to the Tx equalization circuitry. The waveforms that are
output of Tx AMI_GetWave are the waveforms that drive the Analog-Channel. The
waveform that is input to Rx AMI_GetWave is the waveform that is the input to
the Rx buffer. The output of the Rx AMI_GetWave is the waveform at the Rx
decision point, and optionally clock ticks indicating the location of each
recovered clock. The EDA tool processes the waveform at the Rx decision
point, and either uses the clock ticks or the Clock Recovery Mean and Rj to
generate bathtub curves, BER and other channel data.
A
fundamental principle of AMI modeling is that every EDA platform (both
software and hardware) will give the same results when presented with the
same Analog-Channel impulse response, the same AMI model conditions, and the
same input stimulus pattern. Each EDA platform may differ on how its sets the
Tx and Rx AMI model conditions, the stimulus pattern, how it creates the
Analog-Channel impulse response, and how it processes the resulting outputs.
Walter Katz
303.449-2308
Mobile 720.333-1107
wkatz@xxxxxxxxxx
www.sisoft.com
Other related posts:
