****************************************************************************
****************************************************************************
BIRD ID#: {TBD}
ISSUE TITLE: Back-channel support
REQUESTOR: Marcus Van Ierssel, Snowbush IP
Kumar Keshavan, Sigrity, Inc.
Ken Willis, Sigrity, Inc.
Walter Katz, SISoft
DATE SUBMITTED: July 18,2011
DATE REVISED:
DATE ACCEPTED BY IBIS OPEN FORUM:
****************************************************************************
****************************************************************************
STATEMENT OF THE ISSUE:
This BIRD defines how back-channel communications is to be handled in the
IBIS specification. It requires BIRD120 (flow BIRD) and BIRD128 (AMI_GetWave
passing AMI_parameters_out/in) as a prerequisite. This BIRD also
entails:
- new Reserved_Parameters
- definition of a "back-channel" BCI file, with Protocol_Specific parameters
- flow updates to enable the back-channel training to occur
****************************************************************************
STATEMENT OF THE RESOLVED SPECIFICATIONS:
Replace the following text in Section 6c:
| Reserved Parameters:
|
| Init_Returns_Impulse, Use_Init_Output, GetWave_Exists,
| Max_Init_Aggressors and Ignore_Bits
With the following text:
| Reserved Parameters:
|
| Init_Returns_Impulse, Use_Init_Output, GetWave_Exists,
| Max_Init_Aggressors, Ignore_Bits, Training, and Backchannel_Protocol
Add the following text after the description for "Ignore_Bits":
Training:
Training is of usage In and type String. It tells the
EDA platform whether training for back-channel communication
is enabled or not for the associated model. For the back-
channel training to be enabled in the EDA tool, the
Training parameter must be set to "On" for both the
transmitter and receiver of a given through channel. The
syntax for this parameter is as follows:
(Training (Usage In) (Type String) (List “Off” “On”)
(Default “Off”) (Description "Turns training on or off"))
Backchannel_Protocol:
Backchannel_Protocol is of usage In and type String. It tells the
EDA platform what back-channel protocol is to be used for
the back-channel training process. This is defined in a
standard-specific back-channel BCI file. Both the
transmitter and receiver for a given through channel must
have identical settings for the Backchannel_Protocol parameter for
back-channel training to be enabled. An example of the syntax
for this parameter is as follows:
(Backchannel_Protocol (Usage In) (Type String) (List "None" “standard1”
“standard2” “standard3” “standard4") (Default “standard1")
(Description "This Device can support back-channel training for multiple
standards. When “None” is specified, the algorithmic models shall support
standard IBIS flows. When calling the Tx and Rx AMI_Init function, the EDA
tool shall pass the value: <full_path_to>/<protocol>.bci
The EDA tool is responsible for determining <full_path_to>. This file may
be located in the same directory as the .ibs, .ami, dll files or may be
located in library folders controlled by the EDA tool"))
There are a number of Reserved_Parameters that are used solely for the
purpose of enabling back-channel communication, in which a receiver
provides information back to its associated transmitter in order to assist
in optimizing that transmitter's equalization parameters, in the context of
a particular industry standard. These additional back-channel Reserved
Parameters are listed below, and are used only in a back-channel BCI file,
using a .bci file extension:
Reserved Parameters for Back-Channel Communication
Training_Pattern, Preamble, Data, PRBS, LFSR, Length, Postamble
Max_Train_Bits, TrainingDone
Descriptions for each are listed below.
Training_Pattern:
Training_Pattern is of usage Info and is the keyword used to describe the bit pattern
sent from the transmitter to the receiver during the back-channel training.
Preamble:
Preamble is of usage Info and defines the leading bit pattern that starts a
back-channel training Frame.
Data:
Data describes the bit pattern that the EDA tool should generate to serve as
the body of the Frame.
PRBS:
PRBS is described by the sub-parameters LFSR and LFSR_Seed.
LFSR:
LFSR is of usage Info and describes the value associated with a linear
feedback shift register used by the EDA tool for the PRBS generation.
Length:
Length is of usage Info and describes the length of the PRBS pattern to be
generated by the EDA tool.
Postamble:
Postamble is of usage Info and describes the trailing bits used to indicate the
end of the training pattern. This is used by the EDa tool to determine the end
of the particular training pattern.
Max_Train_Bits:
Max_Train_Bits is of usage Info and defines the total number of training bits
that can be sent by a transmitter during the back-channel communication. This
tells the EDA tool when the back-channel training is complete, if the receiver
does not indicate it first with the TrainingDone parameter.
TrainingDone:
TrainingDone is of usage InOut and is issued by the receiver model to signify the
completion of back-channel training. TrainingDone can also be initiated by the EDA
tool. In this case the parameter TrainingDone=True can be passed from the EDA tool
to the receiver model. Then the receiver model will re-issue the parameter
TrainingDone=True to the transmitter model to end the training process.
Also, a BCI file may contain additional parameters in the "Protocol_Specific"
section. This section is analogous to the "Model_Specific" section of an AMI
file, and must abide by the same rules and syntax. The purpose of this section
is to define the protocol-specific parameters that are to be passed back and
forth between the Tx and Rx AMI models during the backchannel training process.
Note that the Tx and Rx AMI models utilizing a particular BCI file must support
the Protocol_Specific parameters defined in that BCI file.
An example template for a back-channel BCI file is given below:
(802.3KR
(Reserved_Parameters
(Training_Pattern (Description "Defines the training pattern")
(Preamble (Usage Info) (Type String) (Value “b11111111111111110000000000000000“)
(Description "Leading preamble pattern."))
(Data (Usage Info) (Type String) (“LFSR 1,9,11 random 4096”)
(Description “Training pattern."))
(Postamble (Usage Info) (Type String) (Value b00)
(Description “Trailing postamble pattern."))
)
(Max_Train_Bits (Usage In) (Type Integer) (Value 500000)
(Description "Number of total training bits allowed"))
(TrainingDone (Usage InOut) (Type Boolean) (List False True)
(Description “If True then training is done"))
)
(Protocol_Specific
(PreTap (Usage InOut) (Type Integer) (List -1 0 1) (Default 0)
(Description "Parameter name is standard-specific, and can be any legal Type"))
(MainTap (Usage InOut) (Type Integer) (List -1 0 1) (Default 0)
(Description "Parameter name is standard-specific, and can be any legal Type"))
(PostTap (Usage InOut) (Type Integer) (List -1 0 1) (Default 0)
(Description "Parameter name is standard-specific, and can be any legal Type"))
)
)
To facilitate the definition of training bit patterns, the syntax shown in the following
example can be utilized:
(Data (Type String) (Usage Info)
(Table
(“b011111111111111110000000000000000 5”)
(“h0123456789ABCDEF0123456789ABCDEF 10”)
(“o01234567012345670123456701234567 10”)
(“File abc.bpi 3”)
(“PRBS 11 b11110000111 1”)
(“LFSR “1,9,11” random 4096”)
(Description “
Strings that begin b,h,o, denote Binary, Hex, Octal.
These bit patterns are followed by a repeat count.
The default is 1, which means the pattern is added once.
Strings that begin with PRBS generate a Pseudo Random Binary Sequence using a Linear
Feedback Shift Register.
PRBS is followed by 3 fields: <duty cycle> <seed> <repeat count>
<duty cycle> A positive, integer number. The PRBS patter will repeat every 2^<duty cycle> bits.
<seed> A non-negative integer number, can be represented as b… or “random for random seed
<repeat count> is non-negative integer number. The number of times this bit pattern is to be
inserted into the stimulus.”))
LFSR is followed by 3 fields: <taps> <seed> <data_len>
<taps> lfsr taps
<seed> A non-negative integer number, can be represented as b… or “random" for random seed
<data len> is optional non-negative integer number. The length of the data pattern generated by
this LFSR in bits. if the value is ‘R’ run it forever.”))
Strings that begin with File reference a file that contains a sequence of binary, octal or hex numbers.
File is followed by two fields: <file name> <repeat count>))
Replace the following text in Section 2.3 of Section 10 (NOTES ON ALGORITHMIC
MODELING INTERFACE AND PROGRAMMING GUIDE), once BIRD120 is incorporated into
the IBIS specification
| 3 Reference Flows
| =================
|
| The next two sections define a reference simulation flow for statistical
| and time domain system analysis simulations. Other methods of calling
| models and processing results may be employed, but the final simulation
| waveforms are expected to match the waveforms produced by this reference
| simulation flow.
|
| A system simulation usually involves a transmitter (Tx) and a receiver
| (Rx) model with a passive channel placed between them.
With the following text:
3 Reference Flows
=================
The next several sections define reference flows for back-channel training,
statistical analysis, and time domain system analysis simulations. Other
methods of calling models and processing results may be employed, but the
final simulation waveforms are expected to match the waveforms produced by
these reference flows.
A system simulation usually involves a transmitter (Tx) and a receiver
(Rx) model with a passive channel placed between them.
3.1 Back-Channel Training Reference Flow
========================================
Some industry standards for serial link interfaces utilize back-channel
communications as a means by which the Rx can communicate back to the Tx
to provide guidance as to the equalization settings of the Tx, to optimize
for the given channel. Once the back-channel training is completed and the
Tx equalization settings are optimized, then time domain simulation is
performed per the "Time domain simulation reference flow" defined later in
this specification.
Note that back-channel training does not apply to statistical simulation,
as back-channel training utilizes the AMI_GetWave function in both the
Tx and Rx, and is therefore not applicable to statistical simulation.
To enable the back-channel training to occur, the .ami files for both Tx
and Rx of a given through channel must have the GetWave_Exists parameter
set as "True", the Training parameter set to "on" and the Backchannel_Protocol
parameter specifying the same back-channel BCI file.
Step 1. The simulation platform obtains the impulse response for the
analog channel, as described in the statistical and time domain simulation
flows.
Step 2. The simulation platform produces a digital stimulus waveform
as defined per the back-channel BCI file. A digital stimulus waveform
is 0.5 when the stimulus is "high", -0.5 when the stimulus is "low",
and may have a value between -0.5 and 0.5 such that transitions occur
when the stimulus crosses 0.
Step 3. The output of Step 2 is presented to the Tx model's AMI_GetWave
function. If the Rx model's AMI_GetWave function has written out the
Protocol_Specific parameters from a previous training sequence, these
parameters are read in. Then the Tx AMI_GetWave function is executed.
The output of the Tx AMI_GetWave function is passed on to Step 4. The
Protocol_Specific parameters defined in the back-channel BCI file are
written out by the Tx model's AMI_GetWave function.
Step 4. The output of Step 3 is convolved with the output of Step 1 by the
simulation platform and the result is passed on to Step 5.
Step 5. The output of Step 4 is presented to the Rx model's AMI_GetWave
function, the Protocol_Specific parameters from the Tx are read in, and the
Rx AMI_GetWave function is executed. The Protocol_Specific parameters are
modified and output by the Rx AMI_GetWave function.
Step 6. Steps 2-5 are executed iteratively until the Rx model's AMI_GetWave
function returns the value of the TrainingDone parameter as "1", or until the
Length parameter defined in the back-channel BCI file is exceeded, whichever
occurs first.
Step 7. With the Tx equalization settings optimized through back-channel
communication, the "Time domain simulation reference flow" is executed directly.
****************************************************************************
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:
Back-channel communication is required for PCI Express Gen 3, 10GBASE-KR,
and other emerging serial link standards. Back-channel capability was
initially developed by Sigrity and Snowbush (IP division of Gennum). It was
deemed desireable to bring this capability to the IBIS standard in order
to encourage other SerDes IP suppliers to enable back-channel functionality
for their IP as well.
****************************************************************************
ANY OTHER BACKGROUND INFORMATION:
The following documents are provided as supporting material for this BIRD:
- "Extending IBIS-AMI to Support Back-Channel Communications", by
Marcus Van Ierssel of Snowbush, Kumar Keshavan of Sigrity, Inc., and Ken
Willis of Sigrity, Inc., delivered at the IBIS Summit on Feb. 3, 2011:
http://www.sigrity.com/papers/2010/IBIS_AMI_Modeling_May_2010.pdf
- "BIRD Proposal: Extending IBIS-AMI to Support Back-Channel Communications",
by Marcus Van Ierssel of Snowbush, Kumar Keshavan of Sigrity, Inc., and Ken
Willis of Sigrity, Inc., delivered at the IBIS-ATM subcommittee meeting on
March 15, 2011:
http://www.vhdl.org/pub/ibis/macromodel_wip/archive/20110315/kenwillis/
Proposed%20BackChannel%20BIRD%20Modifications/Proposal_BackChannel_BIRD_mods.pdf
- "BIRD Proposal: Extending IBIS-AMI to Support Back-Channel Communications",
by Marcus Van Ierssel of Snowbush, Kumar Keshavan of Sigrity, Inc., Ken
Willis of Sigrity, Inc., and Walter Katz of SISoft, Inc, delivered at the IBIS
Summit meeting on June 7, 2011:
http://www.sigrity.com/papers/2011/Backchannel_June_2011.pdf
****************************************************************************