[ibis-macro] Overview of IBIS-AMI sent to the Backchannel Reflector
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: "IBIS-ATM" <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 11 Feb 2011 15:23:23 -0500
All,
One of the members of the IBIS Backchannel Reflector asked for a Tutorial on
IBIS-AMI. Since IBIS has not created such a tutorial, I sent a series of
e-mails to the Backchannel Reflector containing an overview of IBIS-AMI. I
suggest the members of the IBIS-ATM Reflector also subscribe to the
Backchannel Reflector. I am enclosing the e-mails I have sent to the
Backchannel Reflector for your perusal.
Walter
Walter Katz
Chief Scientist
Signal Integrity Software, Inc.
wkatz@xxxxxxxxxx
303.449-2308
--- Begin Message ---
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <ibis-serdes-backchan@xxxxxxxxxxxxx>
- Date: Wed, 9 Feb 2011 08:57:56 -0500
Welcome to the IBIS AMI Backchannel Reflector.
This e-mail was sent to IBIS mailing lists as well as Si-List as an
invitation to join the IBIS AMI Backchannel Reflector. I intend to follow
this up with three e-mails subjects:
1. Is Backchannel an acceptable name.
2. Introduction to AMI Modeling Statistical Analysis
3. Introduction to AMI Modeling Time Domain Analysis
Walter
To subscribe:
The IBIS AMI Backchannel Reflector list is
<mailto:ibis-serdes-backchan@xxxxxxxxxxxxxx>
ibis-serdes-backchan@xxxxxxxxxxxxx
You must be subscribed to post to the list. To subscribe send email to
<mailto:ibis-serdes-backchan-request@xxxxxxxxxxxxx>
ibis-serdes-backchan-request@xxxxxxxxxxxxx
with 'subscribe' in the Subject field
Or, subscribe online at
<//www.freelists.org/list/ibis-serdes-backchan>
//www.freelists.org/list/ibis-serdes-backchan
IBIS AMI Backchannel Reflector Overview
The IBIS AMI Backchannel Reflector is maintained by IBIS
Goal is to produce an IBIS BIRD that will
Enable Channel Standards Groups to define communication protocols between
the Tx and Rx DLLs.
Enable IC Vendors and AMI Model Developers to write IBIS AMI models that are
Portable Model will work with multiple EDA Tools
Interoperable Vendor A Tx will work with Vendor B Rx
Enable EDA Vendors to develop tools that will support AMI Backchannel models
Two presentations and lively discussion was had at the IBIS Summit at
DesignCon 2011. As a result of these presentations and discussions I will
shortly start several e-mail threads in the Backchannel Reflector. One
important issue brought up was the interface layer(s) that need to be
supported (i.e. does the Rx model communicate to the Tx model in commands
like "Increase Pre-Cursor tap by 3", and/or the actual binary stream that
the Rx sends to the Tx.
The complete set of presentations at this year's IBIS Summit can be found at
<http://www.eda.org/ibis/summits/> http://www.eda.org/ibis/summits/
The two papers presented on SerDes Backchannel were:
AMI Backchannel Co-Optimization
Walter Katz
SiSoft
<http://www.eda.org/ibis/summits/feb11/katz2.pdf>
http://www.eda.org/ibis/summits/feb11/katz2.pdf
Extending IBIS-AMI to Support Back-Channel Communications
Kumar Keshavan
Sigrity
<http://www.eda.org/ibis/summits/feb11/keshavan.pdf>
http://www.eda.org/ibis/summits/feb11/keshavan.pdf
Initial discussion topics for the reflector include:
1. Shall we continue to call this "Backchannel"
2. Review of AMI modeling, including statistical and time domain
methodologies.
3. Confirm the mechanism that data is passed back and for the between
the Tx DLL, Rx DLL, and EDA Tool.
4. Determine the generic format of the data passed back and for the
between the Tx DLL, Rx DLL, and EDA Tool.
5. Determine Reserved Parameters that will be used to communicate
information between the EDA Tool and the Rx DLL, and between the EDA Tool
and the Tx DLL.
6. Determine the interface layers that need to be supported.
7. Determine the methodology that Channel Standards Groups (e.g. IEEE
Ethernet, PSIe-Gen3) define communication protocols between the Tx and Rx
DLLs.
8. Consider forming Reflector subgroups that might wish to resolve
issues like the above without overloading the general membership of the
mailing list. Specifically do we need a IEEE Ethernet subgroup and a
PCIe-Gen3 subgroup.
Walter
Walter Katz
<mailto:wkatz@xxxxxxxxxx> wkatz@xxxxxxxxxx
Phone 303.449-2308
Mobile 303.883-2120
--
This message has been scanned for viruses and
dangerous content by <http://www.mailscanner.info/> MailScanner, and is
believed to be clean.
--- End Message ---
--- Begin Message ---
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <ibis-serdes-backchan@xxxxxxxxxxxxx>
- Date: Wed, 9 Feb 2011 09:01:24 -0500
All,
We have been using the name Backchannel to describe the general capability
of a downstream Rx SerDes model communicating to its upstream Tx SerDes
model. It was brought to our attention that the PCIe-Gen3 specification
never mentions the term Backchannel. Does anyone object that we continue to
use the term Backchannel, and if they do can they suggest an alternative
name.
Walter
Walter Katz
Chief Scientist
Signal Integrity Software, Inc.
wkatz@xxxxxxxxxx
303.449-2308
--- End Message ---
--- Begin Message ---
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <ibis-serdes-backchan@xxxxxxxxxxxxx>
- Date: Wed, 9 Feb 2011 09:49:33 -0500
All,
This e-mail is a short introduction to AMI modeling. It is specifically
limited to using AMI modeling to do statistical analysis (similar to
StatEye). My next e-mail thread will describe how AMI modeling is used in
the time domain. At that point we can talk about how AMI modeling can
support various Backchannel simulation strategies.
An Algorithmic Model Interface (AMI) models consists of an executable DLL
and an ASCII .ami file which describes to the EDA tool how to use the DLL.
The DLL contains three entry points; AMI_Init, AMI_GetWave and AMI_Close. A
channel consists of a Tx AMI model, an Rx AMI model and the interconnect
between the Tx and Rx model. Both the Tx and the Rx model are partitioned
into an Algorithmic section and an Analog section. This partitioning is done
by the model make at what we call the "High Impedance Interface". The main
point is that the Analog section of the Tx and Rx model is represented by an
Linear Time Invariant (LTI) analog model, while all of the non-LTI
processing is handle in the Algorithmic section. The Algorithmic section is
captured in the DLL. The .ami file contains information on how to use the
model. The .ami file defines AMI Parameters that represents the registers
that the system can set when configuring the silicon (e.g. tap weights,
strength, peaking filter selection).
The process of using AMI models in a statistical simulation is:
1. The EDA Tool generates an Impulse Response that includes the Tx
Analog Model, the interconnect between the Tx and Rx model, and the Rx
Analog Model.
2. The EDA tool calls the Tx AMI_Init function, passing in the Impulse
Response of the channel and the configuration of the Tx buffer (e.g.
Strength, Tap Coefficients, .)
3. The Tx AMI_Init function returns the Impulse Response of the channel
modified by a set of tap coefficients. These tap coefficients are either the
ones chosen by the user, the EDA tool, or can be generated automatically by
the Tx AMI_Init function.
4. The EDA Tool then calle the Rx AMI_Init function with the
configuration of the Rx model, and the Impulse Response of the channel
modified by the Tx AMI_Init function. The Rx AMI_Init function returns this
Impulse Response modified by the equalization of the Rx Algorithmic model.
The Rx AMI_Init function may optimize its tap coefficients based on the
Impulse Response, or use the tap coefficient specified by the user.
5. The Impulse Response output of Rx AMI_Init is suitable for
statistical analysis.
6. The EDA tool call the Tx and Rx AMI_Close function to free memory
and other computer science niceties.
The good, the bad and the ugly.
The good is that statistical processing is fast, typical simulations take
one second, allowing for the exploration of very large solution spaces.
The bad is that it that handling non LTI affects is problematic. Non-LTI
affects include Jitter, Noise, and certain types of equalization.
The ugly is that handling specific types of adaptive equalization (e.g. DFE)
can be particularly challenging for the model writer.
First, DFE is really LTI. The adaptation process is certainly non-LTI, but
once the DFE has settled to a set of tap coefficients, then an LTI
representation of the DFE is reasonable accurate, and demonstrably accurate
enough to make many design decisions. There not enough room on the margin of
this e-mail to prove the DFE is really LTI, so I will leave that as an
exercise for the reader.
Can statistical analysis be applied to Backchannel? Backchannel is a method
of the Rx communicating to the Tx based on analyzing the data received by
the Rx model. This is fundamentally a time domain process that needs to be
handled by the AMI_GetWave functionality of AMI models. This will be
described in a subsequent e-mail thread to this reflector. However, the Rx
AMI_Init function can have all of the data it needs to determine what the Tx
and Rx configuration will give the optimal waveform at the Rx decision
point. The task of this group will be to define the requirements on Tx and
Rx AMI parameters that will give the Rx AMI_Init function the information it
needs about the Tx AMI Model, and similarly what information the Tx AMI_Init
function needs to know about the Rx model.
Walter
Walter Katz
Chief Scientist
Signal Integrity Software, Inc.
wkatz@xxxxxxxxxx
303.449-2308
--- End Message ---
--- Begin Message ---
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <ibis-serdes-backchan@xxxxxxxxxxxxx>
- Date: Wed, 9 Feb 2011 14:58:47 -0500
All,
In my last e-mail, I described how IBIS AMI models are used to do
statistical analysis. IBIS AMI models are also capable of doing time domain
analysis as well. The same sequence of calls to the AMI_Init functions are
still required. The AMI_Init functions not only generate the data for doing
statistical analysis, they also are used to initialize the DLL to prepare it
for time domain analysis using the AMI_GetWave function. In the current
supported flow, after the Tx AMI_Init and Rx AMI_Init functions are called,
the Tx AMI_GetWave and Rx AMI_GetWave functions are called iteratively.
To be specific, a long stimulus waveform is created in short sections
(~1000UI). The stimulus is a "digital" stimulus with the time of the
transitions including various Jitter impairments such as DCD, Rj, Sj, . The
output of Tx AMI_GetWave is a waveform that includes the algorithmic part of
the Tx equalization. This waveform is normally convolved with the Impulse
Response of the channel to get the waveform that is then input the Rx
AMI_GetWave. The output of the Rx AMI_GetWave call is the waveform at the
decision point of the Rx buffer, along with a list of clock ticks. The EDA
tool processes the waveform and clock ticks on the fly to generate an eye
and a clock PDF.
Simulations of e6 UI and even 100e6 UI are not uncommon. The waveform is
partitioned into small (~1000UI) sections since allocated waveforms 100e6 UI
(with 32 samples per UI) would become unwieldy.
As the EDA Tool alternates between calls to the Tx and Rx AMI_GetWave. The
Rx AMI_GetWave can, based on the quality of the waveform at the Rx decision
point, determine not only improved Rx tap and peaking filter setting, but
can direct the Tx AMI_GetWave function to modify its tap coefficients. This
is the basic mechanism for supporting time domain backchannel
co-optimization. The Rx AMI_GetWave function can model at any level of
detail the method that the RX Silicon actually makes decisions and
recommendations to the Tx AMI_GetWave. This method relies on the Tx and Rx
AMI_GetWave being called on small chunks of the waveform. There are lots of
details to be worked out, like how to communicate to the EDA tool on each
call to Rx AMI_GetWave the data pattern that has to be fed into Tx
AMI_GetWave, and what commands the Rx AMI_GetWave needs to communicate to
the Tx AMI_GetWave.
Walter
Walter Katz
Chief Scientist
Signal Integrity Software, Inc.
wkatz@xxxxxxxxxx
303.449-2308
--- End Message ---
--- Begin Message ---
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <ibis-serdes-backchan@xxxxxxxxxxxxx>
- Date: Thu, 10 Feb 2011 14:05:17 -0500
All,
AMI models consist of executable DLLs and a .ami file. The .ami file is an
ASCII file that defines parameters in a parameter tree format. Each
parameter has a Name, Type (String, Integer, Float, Tap, Boolean), a Usage
(In, Out, InOut, Info), a Description, and a set of Allowed Values.
Usage
In
"In" parameter Values are passed into the DLL The EDA tool is responsible
for selecting a Value for each In parameter based on its allowed values. An
example of an In parameter might be the value of a Tx pre-cursor tap.
Out
"Out" parameter Values are determined by the DLL and passed back to the EDA
tool. An example of an Out parameter might be the value of a DFE tap
determined by the DLL.
InOut
"InOut" parameter Values are passed into the DLL, modified by the DLL and
passed back to the EDA tool. An example of an InOut might be the value of a
DFE tap that can be initialized by the EDA tool to a specific value, but
modified by the DLL as a result of it determining an improved value. In this
case the EDA tool may help the Rx model reach optimized DFE taps quicker by
getting a improved starting value for it.
Info
"Info" parameters are not passed into the DLL, but are used to give
information to the EDA tool on how to use the DLL, or how to process the
data returned by the DLL. An exemple of an Info parameter is Tx_DCD. This
would tell the EDA tool how much duty cycle distortion to apply to the
stimulus pattern input to the DLL in time domain simulation.
Description
EDA tools normally control the usage of an AMI model with a GUI that allows
the user to configure parameters that control the operation of a buffer. The
"Description" is a text string that the EDA tool can use as a tool tip in
this GUI.
Allowed Values
The .ami file has a flexible method that the model make can communicate to
the EDA Tool and User of the model the allowed values that can be assigned
to a parameter. The following methods of specifying "Allowed Values" are:
Value
A single value.
List
An list of allowed values
Range
A range of allowed values
Increment
A range of allowed values constrained to values separated by a
fixed amount
Steps
A range of allowed values constrained to values separated into N
equally spaced steps
Corner
Three values representing typical, slow and fast corners of the buffer
Parameters are divided into two classes; Reserved Parameters and Model
Specific Parameters. Reserved Parameters are defined in the IBIS
specification. Model Specific Parameters are used to define the operation
specific to a model.
The task of this reflector is to create a new set of generic Reserved
Parameters to control the statistical and time domain communications between
Tx and Rx models and the EDA tool, and to define Reserved Parameters for
specific Backchannel Protocols such as PCIe-Gen3, IEEE Ethernet 25G, .
Walter
Walter Katz
Chief Scientist
Signal Integrity Software, Inc.
wkatz@xxxxxxxxxx
303.449-2308
--- End Message ---
--- Begin Message ---
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: "'IBIS-ATM'" <ibis-macro@xxxxxxxxxxxxx>
- Date: Fri, 11 Feb 2011 09:00:05 -0500
IBIS-ATM,
This e-mail is being sent to the IBIS ATM (Advanced Technology Modeling)
group to describe the structural changes required to the IBIS-AMI interface.
The Backchannel Reflector is being cc's as well.
Two changes are required to the IBIS-AMI interface to support backchannel.
The first is to allow the Tx AMI DLL to know what the Rx AMI DLL is telling
it and the Rx AMI DLL needs to know what the Tx AMI DLL is telling it.
Information is currently passed into a DLL as a text string in in a similar
parameter tree format as defined in the .ami file for that model. The roor
of this parameter tree is the root of the parameter tree in the .ami file.
The simple enhancement to the AMI interface is to allow this string to
contain two parameter trees, one with the root of the parameter tree for the
model, and the other tree containing the root of the parameter tree fo the
model at the other end of the channel. The following example should make
this clearer:
Assume that the parameter tree for the Tx model is:
(Tx_Root (FFE_Tap (-1 -.03) (0 .9) (1 -.07)))
and the parameter tree for the Rx model is:
(Rx_Root (DFE_Tap (1 -.1) (2 -.05) (3 .05) (4 .1) (5 -.01)))
In the current standard the Tx just gets the (Tx_Root .) tree and the Rx
just gets the (Rx_Root .) tree.
The proposed change will allow the Tx model to receive:
(Tx_Root (FFE_Tap (-1 -.03) (0 .9) (1 -.07))) (Rx_Root (DFE_Tap (1 -.1) (2
-.05) (3 .05) (4 .1) (5 -.01)))
and the Rx model to receive
(Rx_Root (DFE_Tap (1 -.1) (2 -.05) (3 .05) (4 .1) (5 -.01))) (Tx_Root
(FFE_Tap (-1 -.03) (0 .9) (1 -.07)))
Thus, the Rx model can determine the number of Tx pre-cursor and post-cursor
taps, and the values of all of the Tx taps.
The DLL's not only receive data in this format, but also output data in this
same format. Thus the Rx model can output these same trees with updated
values of the Tx Taps.
As described in previous e-mails, there are three entry points to an AMI
model, AMI_Init, AMI_GetWave, and AMI_Close. The AMI_Init entry has a
parameters_in pointer and a parameters_out pointer. The AMI_GetWave entry
only has a parameters_out pointer. Since Backchannel will require the
ability to pass a parameter tree inot the AMI_GetWave entry, the AMI
interface standard needs to modified to allow the AMI_GetWave parameters_out
pointer to also serve as a pointer to an input string.
To enable the above changes, we will need to define a new Reserved Parameter
to indicate that this DLL does support multiple parameter trees in the input
parameter tree, and that the AMI_GetWave support the parameter_out pointer
use as an input as well as an output.
Walter
Walter Katz
Chief Scientist
Signal Integrity Software, Inc.
wkatz@xxxxxxxxxx
303.449-2308
--- End Message ---
--- Begin Message ---
- From: "Walter Katz" <wkatz@xxxxxxxxxx>
- To: <ibis-serdes-backchan@xxxxxxxxxxxxx>
- Date: Fri, 11 Feb 2011 09:42:32 -0500
All,
The previous e-mails I have sent consisted of an overview of AMI Modeling
and the structural changes required to the IBIS-AMI standard to support
Backchannel Co-Optimization for both statistical and time domain flows. Now
comes the hard part; What "Layers" of Backchannel communications for
specific Backchannel Co_Optimization do we need to define. This is a task
that needs to be addressed by the standards groups (e.g. IEEE Ethernet 25G,
and PCIe-Gen3). There are at least two "Layers" that we need to consider for
time domain simulation. The first is what I call the "Generic Layer", the
second is what I call the "Protocol Layer".
The "Generic Layer" is the simplest approach. The communications from the Rx
to the Tx AMI_GetWave calls simply tell the Tx to increase (or decrease)
each tap by some amount.
The "Protocol Layer" is standard specific. The communications from the Rx to
the Tx AMI_GetWave calls contain the actual binary commands that the Rx send
to the Tx. These binary command are converted within the Tx DLL to changes
in the Tx tap coefficients.
Both the "Generic Layer" and the "Protocol Layer" should give the same
result, but the "Protocol Layer" will give the added capability that the Tx
and Rx models are talking the same language.
This is where we need help from the various standards groups to summarize
and standardize the "Layers" that they want implemented. I would like to
suggest that IEEE Ethernet25G, and PCIe-Gen3 members of this reflector form
subgroups that can discuss this and propose the "Layers" they wish to
define. I suspect that his may require a more formal liaison between IBIS
and the various standards group that will results in standards groups
defining there own standards specific for their interface requirements.
My first request to the members of this reflector is for volunteers to act
as liaison between IBIS and their respective standards group.
Walter
Walter Katz
Chief Scientist
Signal Integrity Software, Inc.
wkatz@xxxxxxxxxx
303.449-2308
--- End Message ---
Other related posts:
- » [ibis-macro] Overview of IBIS-AMI sent to the Backchannel Reflector - Walter Katz
