Quick comment on de-convolution.
We have some experience with it in our other projects, and it is not
as straightforward as it looks. Basically, de-convolution is an
ill-posed problem that is very sensitive to the numerical noise and
particular impulse response used. The theoretical approach of dividing
the fourier spectrums does not work very well in practice, resulting
in very large error, and require sophisticated regularization that is
not guaranteed to work in all cases (see Wiener filter as a simple
example).
I believe this approach should be avoided if possible, since in many
cases it will be extremely hard to produce a reliable answer.
Best,
Danil
*From:* ibis-macro-bounce@xxxxxxxxxxxxx
[mailto:ibis-macro-bounce@xxxxxxxxxxxxx] *On Behalf Of *Walter Katz
*Sent:* Monday, October 12, 2009 7:39 PM
*To:* fangyi_rao@xxxxxxxxxxx; ibis-macro@xxxxxxxxxxxxx
*Subject:* [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
