[ibis-macro] Re: An AMI Overview

  • From: "C. Kumar" <kumarchi@xxxxxxxxx>
  • To: wkatz@xxxxxxxxxx, ibis-macro@xxxxxxxxxxxxx, fangyi_rao@xxxxxxxxxxx
  • Date: Mon, 12 Oct 2009 18:53:40 -0700 (PDT)

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: