**************************************************************************** **************************************************************************** BIRD ID#: 147 ISSUE TITLE: Back-channel support REQUESTOR: Marcus Van Ierssel, Snowbush IP; Kumar Keshavan, Sigrity, Inc.; Ken Willis, Sigrity, Inc.; Walter Katz, SiSoft DATE SUBMITTED: October 18, 2011 DATE REVISED: DATE ACCEPTED BY IBIS OPEN FORUM: **************************************************************************** **************************************************************************** STATEMENT OF THE ISSUE: This BIRD defines how back-channel communications are to be handled in the IBIS specification. It requires BIRD120 (flow BIRD) and BIRD128 (AMI_GetWave passing AMI_parameters_out/in) as prerequisites. 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: /.bci The EDA tool is responsible for determining . 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: A positive, integer number. The PRBS pattern will repeat every 2^ bits. A non-negative integer number, can be represented as "b" or "random" for random seed 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: lfsr taps A non-negative integer number, can be represented as "b" or "random" for random seed 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: )) 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 desirable 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 ****************************************************************************