creating an adaptive ctle ami model - john baprawski...jun 25, 2012 · occur in the receiver using...

Creating an Adaptive CTLE AMI Model 2012

Copyright © 2012 John Baprawski

Creating an Adaptive CTLE AMI Model

Author: John Baprawski

Date: June 25, 2012

Introduction

High speed digital (HSD) integrated circuits (ICs) are used in Serializer/Deserializer (SerDes)

systems. In such systems, a lossy channel exists between the transmitter (Tx) circuit and the

receiver (Rx) circuit. At high data rates the received data stream is severely distorted and

requires reconstruction (equalization) before use. For system design, there is often the need to

model an Rx continuous time linear equalizer (CTLE) that adapts to the channel loss

characteristics.

This modeling work is typically done by signal integrity (SI) engineers to convert circuits into

Input/Output Buffer Information specification (IBIS) models using the IBIS AMI (Algorithmic

Modeling Interface) standard to achieve fast simulations for evaluation and performance

prediction.

This paper contains three parts with the following outline:

Overview: The application overview is discussed.

o General SerDes system

o Define a set of channel characteristics

o Define a reference equalized channel response

o Define a set of equalization CTLE responses

o Define a feedback algorithm to adaptively select the CTLE

Implementation: The implementation approach taken using the SystemVue 2011.10 and

ADS 2011.10 tools is discussed.

o Creating the SystemVue workspace

o Importing S-parameter files into SystemVue

o Testing the channels

o Testing the CTLE detection process

o Defining the RxAdaptiveCTLE subnetwork model

o Using the RxAdaptiveCTLE in a SerDes system design

o Generating C++ models for the RxAdaptiveCTLE subnetwork

Generating the SystemVue C++ model

Generating the portable AMI C++ model

o Using the RxAdaptiveCTLE AMI model in the ADS ChannelSim

Modification: User modification of the application implementation for their own CTLE

characteristics and adaption control is discussed.

o Modifying the set of CTLE filters

o Modifying the CTLE BPF filter

o Modifying the feedback algorithm



Limitations and Solutions

OVERVIEW

One common approach to modeling an adaptive CTLE is to follow these steps:

Define a set of channel characteristics to serve as the reference set for equalization.

Define a reference equalized channel response.

Define a set of equalization CTLE responses associated with the set of reference

channels to achieve the reference equalized channel response.

Define a feedback algorithm to adaptively select the CTLE.

The following Implementation section will discuss the process for combining the pieces into a

solution for a portable IBIS AMI model.

This article will introduce the reader to one approach to achieve the adaptive CTLE model for a

defined set of channels, reference equalized channel response, set of equalization CTLEs, and

feedback signal energy detection process for CTLE selection control. The methodology

discussed is adaptable for other user defined channels, CTLEs and feedback algorithms.

For a discussion on the basics of a CTLE, see the companion article from this author: “SerDes

System CTLE Basics”; http://www.johnbaprawski.com/2012/04/01/serdes-system-ctle-basics.

For a discussion on using SPICE frequency domain data in CTLE models, see the companion

article from this author: “Using SPICE Frequency Domain Data in CTLE Models”;

http://www.johnbaprawski.com/2012/04/01/using-spice-frequency-domain-data-in-ctle-models.

This article is an example on using the Agilent products SystemVue and ADS to generate C++

code and create a portable IBIS AMI model for an Adaptive CTLE.

The tools and files associated with this article are:

Advanced Design System (ADS) 2011.10

SystemVue 2011.10

Visual Studio (VS) 2008 SP1 (free Express Edition or Professional Edition)

Archive file associated with this document is AdaptiveCTLE.7z and contains this content:

http://www.johnbaprawski.com/2012/04/01/serdes-system-ctle-basics/


http://www.johnbaprawski.com/2012/04/01/serdes-system-ctle-basics


http://www.johnbaprawski.com/2012/04/01/using-spice-frequency-domain-data-in-ctle-models



Where

Creating_an_Adaptive_CTLE_AMI_Model.pdf: is this document

*.s2p files: define the 13 SerDes channels discussed

AdaptiveCTLE.wrk: SystemVue 2011.10 workspace file

AdaptiveCTLE: Visual Studio 2008 SP1 Solution for custom SystemVue C++ models and

exported and portable AMI models.

AdaptiveCTLE_wrk: ADS 2011.10 workspace

This article and zip archive is available from the author’s web site at:

http://www.johnbaprawski.com/2012/06/25/creating-an-adaptive-ctle-ami-model

For discussion purposes in this article, it is presumed that the content of this zip file are place in

the PC directory C:\AMI.

General SerDes System

Figure 1 shows a general SerDes system:

http://www.johnbaprawski.com/2012/06/25/creating-an-adaptive-ctle-ami-model



Figure 1. A general SerDes system

The typical SerDes system contains input data, serializer, transmitter (TX), channel, receiver (RX), deserializer and output data. The serial data bit stream is input to the transmitter. The transmitter consists of an equalizer (EQ) and a linear analog backend that includes packaging effects. The channel between the transmit backend and receiver front end consists of transmission lines (TL) that may include wiring and printed circuit board traces. The receiver front end includes packaging effects. The receiver contains signal processing with an EQ and clock and data recovery (CDR). Though the channel in real systems has multiple input and output pins, typically with differential input and output pin pairs, the discussion in this article is as a channel with a single ended input and output.

Define a Set of Channel Characteristics The typical SerDes system channel is a linear system that contains high frequency attenuation of the transmitted signal. One specific SerDes system many need to work with many different system channels. Figure 2 shows a set of 13 SerDes channel characteristics in the frequency domain that is typical for a SerDes system. For discussion in this article, the data used with these channels has a 100 psec bit time (10 Gbps bit rate). The figure y-axis is in dB units.

Figure 2: Channel Attenuation vs Frequency



This set of curves is representative of any set of frequency domain channel characteristics. Most practical systems have characteristics that include a lot of irregularity due to system mismatches and signal suck-outs. This simplified set of curves is for discussion purposes in this article. The table in Figure 2 shows the list of 13 channels referenced by ‘Index’ number along with the channel DC (0 GHz) gain, gain at 5 GHz which is the Nyquist frequency for the 10 Gbps data stream, and gain at 10 GHz. The channel attenuation at 5 GHz varies from -16.4 dB to -32.7 dB, with about -1 to -2 dB change per step in Index value. This high frequency attenuation needs to be restored to a flat response within the Nyquist frequency band (0 – 5 GHz) to achieve low data bit error rates in the SerDes system. Though equalization is typically implemented in both the transmitter and in the receiver, for the purpose of discussion in this article, it will be assumed that all of the channel equalization will occur in the receiver using a Discrete Time Linear Equalizer (DLE) CTLE.

Define a Reference Equalized Channel Response

For each channel characteristic, a CTLE can be designed that restores the system response to

that for a defined reference channel.

Figure 3.a shows the reference equalized channel frequency domain response used in this discussion and Figure 3.b shows its associated eye diagram response.

Figure 3.a: Reference Equalized Channel Attenuation vs Frequency

This frequency domain response has a slight peaking at 2.5 GHz and a gain of about -0.8 dB at the Nyquist frequency (5 GHz) and is down by over -60 dB at the bit rate (10 GHz).



Figure 3.b: Reference Equalized Channel Eye Diagram Response The eye diagram, at the optimal sampling instant, is wide open with zero intersymbol interference and high and low levels of +/- 0.5 V. This eye diagram is optimal for discussion in this paper due to the use of an optimal CTLE. The actual Rx CTLE implementation in hardware SerDes systems is typically sub-optimal but still with a wide open eye.

Define a set of equalization CTLE responses Figure 4 shows a set of 13 CTLE characteristics in the frequency domain used to equalize the set of 13 channel characteristics shown above. The figure y-axis is in dB units.

Figure 4: Receiver CTLE Gain vs Frequency



The CTLE for the channel with the lowest loss (Channel 1) has the smallest gain. The one for the highest loss (Channel 13) has the greatest grain. Conceptually, each of the CTLE characteristics is associated with an HSD IC circuit design. SPICE circuit simulations can be used to obtain the frequency domain characteristic for each CTLE. Though these CTLE responses are idealized, actual circuit CTLE responses will be different. One CTLE design will equalize one channel.

Define a Feedback Algorithm to Adaptively Select the CTLE

There are many ways to define an adaptive CTLE feedback control algorithm. Many

approaches detect the CTLE output signal energy through low, high or bandpass filtering

structures. The approach taken here is to use a 2nd order Butterworth bandpass filter (BPF)

centered at the signal Nyquist frequency (5 GHz in this discussion) with BitRate/4 bandwidth at

the output of the CTLE. The average signal energy at the output of the bandpass filter is

detected. For a given CTLE, if the detected energy is below a defined threshold, then the CTLE

is not providing enough gain at the Nyquist frequency and a CTLE providing more gain needs to

be selected. The detected level at the BPF output can be used in a feedback loop and

compared against the defined threshold level to drive the CTLE towards the desired CTLE state.

Figure 5 shows the BPF frequency domain filter response superimposed on the reference

equalized channel response shown in Figure 3a.

Figure 5: CTLE BPF Attenuation vs Frequency



As seen in this figure, the BPF provides unity gain at the Nyquist frequency with rolloff before

and after the Nyquist frequency.

The energy at the output of the BPF can be detected and averaged over a number of signal bit

time intervals using an accumulate, detect and hold detection process.

Figure 6 shows the accumulate, detect and hold characteristic for the CTLE BPF output when

used with the reference equalized channel and data generated using pseudo random binary

sequence (PRBS) generator. The PRBS generator has an 8 bit linear feedback shift register

length. The accumulate period is for 200 bits.

Figure 6: CTLE BPF output Accumulate, Detect, and Hold Characteristic

As can be seen, the detected average value is about 0.15 volts. After the initial start up

transient, the detected voltage spread is about +/- 0.5 dB. This spread is less than the minimum

step in level at the Nyquist frequency for consecutive channels in the set of 13 channels.

When the PRBS length is changed, the detection accumulate period should be changed

accordingly to retain the same detection statistics.

Figure 7 shows the block diagram for the CTLE feedback loop.



Figure 7: CTLE Feedback Loop Block Diagram

As can be seen, the feedback loop provides feedback to the CTLE to select the best CTLE

response based on the detected CTLE output.

With the set of channels defined, the reference equalized channel defined, the set of CTLE

characteristics associated with the set of channel defined, and with the CTLE output detection

process defined, we are ready to assemble these pieces into a solution to achieve a portable

IBIS AMI model.

IMPLEMENTATION

The adaptive CTLE application is implemented using SystemVue 2011.10. The adaptive CTLE

model created is exported as a C++ AMI model using the SystemVue C++ Code Generator.

The resultant AMI model is used in an ADS 2011.10 schematic with the ADS ChannelSim

simulator.

To use the SystemVue workspaces discussed in this section the AdaptiveCTLE dll needs to be

loaded into SystemVue. The 32-bit Windows dll is located in the directory

AdaptiveCTLE\ReleaseSystemVue\AdaptiveCTLE.dll. The 64-bit Windows dll is located in the

directory AdaptiveCTLE\x64\ReleaseSystemVue\AdaptiveCTLE.dll. Use the SystemVue Tools

menu > Library Manager … > Add From File … dialog and select the dll from its directory.

Creating the SystemVue workspace



The SystemVue workspace created is AdaptiveCTLE.wsv and included in the zip file associated

with this article.

The steps creating this SystemVue workspace includes:

Importing the S-parameter files associated with the set of SerDes channels.

Testing the channels

Testing the CTLE detection process

Defining the RxAdaptiveCTLE subnetwork model

Using the RxAdaptiveCTLE subnetwork model in a SerDes system design.

Importing S-Parameter Files into SystemVue

In general SystemVue supports using S-parameter files containing many ports. However, for

use in SystemVue DataFlow simulations, only two ports are used from any N-port S-parameter

file. Thus, the set of SerDes channels to be used in a SystemVue DataFlow simulation should

be defined as 2-port S-parameter files. ADS can be used to convert SerDes channels with a

differential input and output into 2-port S-parameter files.

For convenience, place the S2P files into the same directory as where the AdaptiveCTLE.wsv

file exists.

Figure 8 shows the SystemVue menu structure used for importing S-parameter files.

Figure 8: Importing S-Parameter files into SystemVue.

Using this approach, the set of 13 channel S2P files are imported into SystemVue.

Figure 9 shows the resultant SystemVue workspace tree listing the imported S-parameter files.



Figure 9: SystemVue Workspace Tree with Imported S-Parameter Files

Testing the Channels

To test the imported channels, a workspace folder named ‘SerDes_Channel_test’ is created

containing schematic Channel_Schematic and DataFlow analysis Channel_Analysis.

The equation sheet System_Data is also created to define the BitRate, SamplesPerBit,

construct a string for the S2P channel to be analyzed, and define the number of samples to be

used in the channel analysis.

Figure 10 shows the Channel_Schematic.



Figure 10: Channel_Schematic

Within the Channel_Schematic, the SystemVue SData block uses the S-parameter data defined

by the string ChannelName. The custom model VtCTLE_FIR contains the set of 13 CTLE FIR

filters. The filter used is selected by input CTLE_Control defined by the Const2 Value =

CTLE_Index defined in the System_Data equation sheet as 13. The schematic equation view

defines SampleInterval = 1/BitRate/SamplesPerBit.

The custom VtCTLE_FIR model will be discussed in more detail in the following

MODIFICATION section.

The Channel_Schematic contains three paths for measuring the impulse and spectrum for the

Channel, Channel + CTLE and CTLE alone.

Figure 11 shows the frequency domain response for these the paths.



Figure 11: Frequency Domain Response for Channel, Channel + CTLE and CTLE alone

As can be seen, the cascade of the CTLE with the Channel restores the combined response

very close to the reference equalized channel response defined in Figure 3a.

Testing the CTLE detection process

The CTLE detection process is added to the workspace tree by adding a folder named

CTLE_Detection_test with schematic CTLE_Detection_Schematic and analysis

CTLE_Detction_Analysis.

Figure 12 shows the CTLE_Detection_Schematic.

Figure 12: CTLE Detection Schematic



As was discussed in the prior section, the CTLE output detection process is based on using at

the output of the CTLE a 2nd order Butterworth bandpass filter (BPF) centered at the signal

Nyquist frequency (5 GHz in this discussion) with BitRate/4 bandwidth. The CTLE in this case

is the reference equalized channel. The CTLE_BPF block in this schematic is this Butterworth

bandpass filter. The CTLE_Detection block in this schematic is a custom SystemVue model that

performs the detection process defined in the prior section with parameters entered for the

SamplesPerBit and NumBitsToAvg.

The DetectionOutput is the Hold characteristic shown in Figure 6.

Defining the RxAdaptiveCTLE subnetwork model

Now that all the pieces are together, the RxAdaptiveCTLE model will be defined as a

subnetwork in a folder added to the workspace tree named ‘Transceivers’.

Figure 13 shows the RxAdaptiveCTLE subnetwork schematic

Figure 13: RxAdaptiveCTLE Subnetwork Schematic

Within this schematic, blocks previously defined are used: VtCTLE_FIR, CTLE_BPF and

CTLE_Detection.

Custom block CTLE_Control implements the control algorithm to set the CTLE_Index value into

the VtCTLE_FIR. Its input is the DetV value output from the CTLE_Detection block. Its

parameters are BitRate, SamplesPerBit, NumBitsToAvg, TargetV, ThresholdV, IndexInit and

EnableEQ. Its output is CTLE_IndexV which is that value that sets the CTLE in the

VtCTLE_FIR block.



When EnableEQ = 0 (false), the output CTLE_IndexV is fixed at the value IndexInit.

When EnableEQ = 1 (true), the CTLE_IndexV is set every sample count of

NumBitsToAvg*SamplesPerBit using this algorithm:

if ( DetV < TargetV-ThresholdV ) CTLE_Index++; if ( DetV > TargetV+ThresholdV ) CTLE_Index--; if ( CTLE_Index < 1 ) CTLE_Index = 1; if ( CTLE_Index > 13 ) CTLE_Index = 13;

In this way, the state of the VtCTLE_FIR achieves the feedback control to the optimal level for

CTLE output detection.

The ClockRecovery block is a subcircuit that provides a clock recovery mechanism based on

zero crossings and an internal phase detector, VCO and phase lock loop.

The ClockTimes block converts the clock signal to clock times based on the IBIS AMI standard.

The Delay block is in the VtCTLE_FIR output path since for DataFlow simulations any feedback

path requires at least one sample delay. This effectively does not affect the simulation results.

Sinks are included in the design to record the values for DetV and CTLE_IndexV.

Using RxAdaptiveCTLE in a SerDes System Design

The RxAdaptiveCTLE model will used in a SerDes system design in a folder added to the

workspace tree named ‘SerDes_System’.

Figure 14 shows the SerDes_System_Schematic.



Figure 14: SerDes System Schematic

As can be seen, the SerDes system consists of a data source (instance PRBS +

PulseShapper), channel (instance SData) and the receiver block (instance AdaptiveCTLE). The

AdaptiveCTLE is an instance of the RAdaptiveCTLE.

The system is set for use with Channel 13. The AdaptiveCTLE has its IndexInit = 7 and

NumBitsToAvg = 200. The AdaptiveCTLE is setup to have a start up transient of

3*NumBitsToAvg = 600 bits. Since the CTLE_Index can change +/- 1 only once every

NumBitsToAvg = 200, the AdaptiveCTLE will require at least 600 + (13-7)*200 = 1600 bits to

settle to it operating point for Channel 13. 1600 bits = 1600*100 psec = 160 nsec.

Within the AdaptiveCTLE, the sinks CTLE_IndexV and DetV are setup to record to 400 nsec.

The system RxOut sink is setup to record from 300 nsec to 400 nsec.

Figure 15a and b shows the eye diagram generated at RxIn and RxOut.



Figure 15a: Eye Diagram at RxIn

Figure 15b: Eye Diagram at RxOut

As can be seen the Rx input eye is totally closed as would be expected for Channel 13 which

has 33 dB loss at the Nyquist frequency. The Rx output eye is totally open with amplitude

restored since the feedback control action in the AdaptiveCTLE resulted in automatic selection

of the optimal CTLE which is with CTLE_Index = 13 for this case.



Before the AdaptiveCTLE stabilizes at the optimal CTLE_Index, the eye will be degraded.

Figure 16 shows the AdaptiveCTLE CTLE_Index versus time.

Figure 16: Adaptive CTLE Index vs Time

As can be seen, the value starts at the IndexInit value of 7 and incrementally steps towards 13

each 400 bits and reaching 13 at about 160 nsec.

Figure 17 shows the detected voltage, DetV, versus time.



Figure 17: Detected CTLE Output Value vs Time

As can be seen, the DetV value sits at the defined TargetV value for the first three periods of

200 bits. After that, the distance from that value represents how far the CTLE Index value is

from its optimal value. After 180 nsec, the DetV value is within +/- ThresholdV (0.015) from the

TargetV. Thus, after 180 nsec, the CTLE_Index does not change and is considered to have

reached its stable value.

This successful simulation and more simulations operating over all system conditions of interest

lead to the conclusion that the RxAdaptiveCTLE subnetwork design is indeed the one desired

for use as an AMI model in Channel Simulators such as the ADS ChannelSim.

The next step is to generate the portable C++ model for the RxAdaptiveCTLE subnetwork

Generating C++ Models for the RxAdaptiveCTLE Subnetwork

The C++ models will be generated using the SystemVue code generator. This converts a

subnetwork design into C++ code which when compiled and linked results in a model that can

be used in SV or a model that is portable and usable in other tools.

There are two C++ code generation steps of interest.

The first is to generate a SystemVue C++ model for RxAdaptiveCTLE and use it in SystemVue.

This is a validation step to verify that the C++ code generated by SystemVue is still usable and

provides the same simulation results as the RxAdaptiveCTLE subnetwork in SystemVue

simulations.



The second step is to generate a portable AMI C++ model with associated *.ami, *.dll and *.so

files that are compliant with the industry IBIS AMI standard. These portable AMI models will

them be portable and usable in an Channel Simulator that is compliant to the IBIS AMI

standard.

Before generating the C++ code, the two Sinks, CTLE_IndexV and DetV, in the

RxAdaptiveCTLE subnetwork need to be deactivated since Sinks are not allowed for use with

the code generator.

Generating the SystemVue C++ Model

To generate the SystemVue C++ model, the SystemVue C++ Code Generator is used with

Target Configuration set to SystemVue as shown in this figure.

Figure 18: SystemVue C++ Code Generator Dialog for SystemVue Models

Note that ‘Automatically add generated model to Part model list’ is checked.

Also, make sure that the SystemVue Global Options, C++ Compile/Build Configuration is set.



Figure 19: SystemVue C++ Code Generator Global Options

When the code generator is run, the model RxAdaptiveCTLE is generated in the AdaptiveCTLE

VS solution SystemVue project.

These successful code generation information lines are displayed in SystemVue:

The compiling and linking of the SystemVue project will have been completed successfully for

the Release configuration.

To use the generated SystemVue C++ model, first unload the AdaptiveCTLE.dll from

SystemVue by going to ‘Tools > Library Manager …’ and selecting ‘AdaptiveCTLE Models’ from

the Library list and selecting ‘Remove Library’. Then, reload the library by using ‘Tools > Library

Manager … > Add From File …’ dialog and select the dll from its directory.

The generated SystemVue C++ model can be used in the SerDes_System_Schematic

simulations by selecting the model in the AdaptiveCTLE Model list.

Figure 20: AdaptiveCTLE model Properties dialog model selection

When the SerDes_System_Analysis is run with this new C++ model, the simulation results

should be the same as was produced using the subnetwork model.



Note: The Sinks CTLE_Index and DetV which were in the subnetwork are not in the generated

C++ model, so there will be no data generated for those sinks.

When this step is successful, the C++ model generation has been validated.

The next code generation step can then be taken to generate an AMI wrapper around this

model and make it portable for use in Channel Simulators.

Generating the Portable AMI C++ Model

To generate the SystemVue C++ AMI model, the SystemVue C++ Code Generator is used with

Target Configuration = ‘IBIS Algorithmic Modeling Interface’ as shown in this figure.

Figure 21: SystemVue C++ Code Generator Dialog for AMI Models

In the ‘AMI Configuration’ tab, notice the settings: Rx, NLTV, Waveform = output (the name of

the subnetwork output port), Clock Times = clockTimes (the name of the subnetwork clock times



port), Bit Time = BitTime (subnetwork parameter), Samples Per Bit = SamplesPerBit

(subnetwork parameter).

In the ‘AMI Model Specific Parameters’ tab, the additional subnetwork model parameters are set

up for export:

Figure 22: Code Generator AMI Model Specific Parameters Dialog

Within this dialog, the default values are set. Notice that the NumBitsToAvg = 200, TargetV =

0.15, CTLE_Init = 7 and ThresholdV = 0.015.

In the ‘AMI Reserved Parameters’ tab, the Ignore_Bits parameter is set for export with default

10000:

Figure 23: Code Generator AMI Reserved Parameters Dialog

When the code generator is run, the project RxAdaptiveCTLE is generated in the AdaptiveCTLE

VS solution.

These successful code generation information lines are displayed in SystemVue:

The compiling will not have been completed because this project needs to have its references to

the custom SystemVue C++ model completed. Within the VS RxAdaptiveCTLE project, changes

need to be made to file RxAdaptiveCTLE.h located in the ‘Solution Explorer’ ‘RxAdaptiveCTLE

> Header Files’ folder.

Change these lines:

#include "CTLE_Detection.h"

#include "CTLE_BPF.h"

#include "VtCTLE_FIR.h"



#include "CTLE_Control.h"

To:

#include "../../SystemVue/CTLE_Detection.h"

#include "../../SystemVue/CTLE_BPF.h"

#include "../../SystemVue/VtCTLE_FIR.h"

#include "../../SystemVue/CTLE_Control.h"

Also, the files for these custom SystemVue model need to be added to the RxAdaptiveCTLE

project ‘Header Files’ and ‘Source Files’ folders. For each of these folders, right mouse click on

the folder in VS and select ‘Add > Existing Item…’.

Figure 24: Adding files to the RxAdaptive project in the Solution Explorer

Go to the VS SystemVue directory on the computer and select the files to bring them into the

Solution project:

Change the Solution RxAdaptiveCTLE project view in the Solution Explorer from:

To:



Now, the RxAdaptiveCTLE project is complete in the VS Solution and can be built (compiled

and linked). Build the 32-bit and 64-bit configurations. The 64-bit configuration requires use of

VS 2008 SP1 Standard Edition (not the Express Edition).

When built, these portable AMI model files will exist in the PC directories:

C:\AMI\AdaptiveCTLE\AdaptiveCTLE\ReleaseAMI\ RxAdaptiveCTLE.dll: 32-bit dll

C:\AMI\AdaptiveCTLE\AdaptiveCTLE\ReleaseAMI\ RxAdaptiveCTLE_x64.dll: 64-bit dll

C:\AMI\AdaptiveCTLE\AdaptiveCTLE\AMI\RxAdaptiveCTLE\ RxAdaptiveCTLE.ami

C:\AMI\AdaptiveCTLE\AdaptiveCTLE\AMI\RxAdaptiveCTLE\RxAdaptiveCTLE_ibis.txt

A 64-bit Linux build can also be created by following the SystemVue documented instructions.

With these portable AMI model files created, they can then be used in a Channel Simulator.

Using the RxAdaptiveCTLE AMI model in the ADS ChannelSim

Using the ADS workspace AdaptiveCTLE_wrk, the portable AMI model files listed in the prior

section are to be copied to the AdaptiveCTLE_wrk/data directory.

The content from the RxAdaptiveCTLE_ibis.txt file is used in creating the RxAdaptiveCTLE.ibs

file. This *.ibs file is setup as a receiver AMI model with 50 ohm termination resistance for each

differential input.

The workspace schematic AMI_SerDes_System is shown here:



Figure 25: AMI_SerDes_System schematics

The Tx_AMI model uses the EEsof_Tx_Pass_Through model which is installed into the

workspace data directory by using the ADS Tools menu ‘DesignGuide > IBIS AMI’ and selecting

‘Tx Pass Though’. The Tx_AMI PRBS tab is set for ‘Bit rate = 10 Gbps’ and LSFR ‘Register

length = 8.

The channel is setup for use with ‘Channel_13’.

The Rx_AMI model is the RxAdaptiveCTLE AMI model.

The ChannelSim controller is set with its default setting.

Figure 26 shows the resultant RxAdaptiveCTLE output Eye Density plot when the ChannelSim

is run.



Figure 26: ADS ChannelSim Eye Density Plot for the RxAdaptiveCTLE using Channel 13.

This concludes the Implementation discussion. Next is discussion on modifying this solution.

MODIFICATION

The adaptive CTLE modeling approach discussed above is for a specific set of channels,

reference channel, set of CTLE filters and specific feedback algorithm.

For practical applications, all of this needs to be customized as needed.

This section discusses steps to take to modify the set of CTLE filters, the CTLE BPF filter and

the feedback algorithm.

Modifying the set of CTLE filters

The CTLE filters are defined in the files:

AdaptiveCTLE\AdaptiveCTLE\SystemVue\CTLE_FIR_taps_data.txt

AdaptiveCTLE\AdaptiveCTLE\SystemVue\CTLE_FIR_gain_file.txt

These files are used in the SystemVue project source file CTLE_FIR.cpp which is further used

by the file VtCTLE_FIR.cpp.



Both of these files can be changes as needed.

As used in CTLE_FIR.cpp, these are the relevant lines of code:

#define NUMRESPONSES 13

static double CTLE_impulse_file[][NUMRESPONSES+1] = {

#include "CTLE_FIR_taps_data.txt"

};

static double CTLE_gain_file[][NUMRESPONSES] = {

#include "CTLE_FIR_gain_file.txt"

};

As used, the file CTLE_FIR_taps_data.txt contains 14 columns of data and N rows. The first

column represents the time stamp for each row. The following columns represent the FIR tap

coefficients for each CTLE filter.

This is the structure for this file:

{ time, tap_filter1, tap_filter2, tap_filter3, …, tap_filterN },

Where N is the number of CTLE filters.

The file CTLE_FIR_taps_data.txt can be changed with data as needed. If the number of filters

is other than 13, then the value for NUMRESPONSE should be changed accordingly.

Since all columns have the same row size, the maximum row size is set by the filter with the

maximum number of taps. Other filters with less taps would just have their additional rows zero

filled.

The file CTLE_FIR_gain_file.txt is used to set the filter step response gain. This file has only

one row. This is the file structure for this file:

{ gain1, gain2, gain3, …, gainN },

Where N is the number of CTLE filters.

Modifying the CTLE BPF filter

The CTLE BPF filter is defined in the file:

AdaptiveCTLE\AdaptiveCTLE\SystemVue\BPF_taps_data.txt

This file is used in the SystemVue project source file CTLE_BPF.cpp.

This file can be changes as needed.

As used in CTLE_BPF.cpp, these are the relevant lines of code:



#define NUMRESPONSES 1

static double CTLE_impulse_file[][NUMRESPONSES+1] = {

#include "BPF_taps_data.txt"

};

As used, the file BPF_taps_data.txt contains 2 columns of data and N rows. The first column

represents the time stamp for each row. The following column represents the FIR tap

coefficients for the BPF filter.

This is the structure for this file:

{ time, tap_filter1 },

If desired, more than one filter can be defined by adding columns to this file.

The file BPF_taps_data.txt can be changed with data as needed. If the number of filters is other

than 1, then the value for NUMRESPONSE should be changed accordingly.

Modifying the feedback algorithm

The feedback algorithm is defined with the combination of the CTLE_BPF, CTLE_Detection and

CTLE_Control. All three of these models are in the SystemVue project in the VS Solution

Explorer.

The CTLE_BPF and CTLE_Control were discussed above.

The CTLE_Detection model performs the accumulate, average and hold detection process on

the CTLE_BPF output.

The algorithms in these files can be changed as needed.

Limitations and Solutions

The methodology discussed in this article was very focused but general in nature. Though it

uses very specific channels, CTLE characteristics, feedback algorithm and data rate, the

methodology is general purpose for using other channels, CTLEs, and feedback algorithm in

AMI models.

There are limitations in the methodology presented. Fortunately, there are solutions for many of

the limitations.

Only 13 Channel and CTLE states were used.



In actual practice, it is very reasonable for there to be many more states. In fact, 1024

states have been used in another application.

The CTLEs were defined to provide all of the equalization for the channels.

In actual practice, the equalization is often split up between transmitter pre-emphasis,

receiver CTLE and receiver DFE. There may be multiple stages in each area as well.

Regardless, however the CTLE characteristics are defined, they can be used in this

methodology.

The CTLE responses used provided ideal equalization for the channels used.

In actual practice, the analog circuits utilized in HSD ICs provide only a close

approximation to the ideal equalization characteristic needed. Determining a practical

equalization characteristic usable in a HSD IC can be more of an art. Various design

techniques are available for creating such approximate equalization characteristics.

Sometimes, it is desirable to for the SerDes receiver to include not only a CLTE, but also

a CDR, DFE, and other nonlinearities. The SerDes receiver can be as complex as

needed. Custom receiver AMI models with CTLE, DFE, CDR and other nonlinearities

have been created and are available as needed.

The CTLE FIR data was used at the same data rate used to generate the data.

Typically, the FIR data needs to be used at other data rates and samples per bit. In

most cases, the custom CTLE_FIR model provides proper analytical processing to

automatically change the CTLE tap coefficients needed for the other data rates and

samples per bit while retaining the specified frequency domain characteristic.

The feedback algorithm was based on detection of the signal energy at the BPF output after the

CTLE.

Other feedback algorithm approaches can also be used such as with other LPF, HPF

and BPF structures.

The feedback target detection level was used for data with PRBS register length of 8.

For other data patterns, the target detection level should be changed accordingly. It is

possible to define a set of detection levels suitable for a set of data patterns.

The example provides only dlls for use on Windows.

Linux is an important platform for SI designers. The process easily supports Linux as

well and has been done for such cases. See the SystemVue documentation for the

Linux build process.

The methodology defined used Microsoft Visual Studio 2008 SP1.



Sometimes, one would like to use the Microsoft Visual Studio 2010 product. The

methodology can be adapted for use with VS 2010.

As with any focused presentation, there is often more work involved from discussion to practical

application. Practical application is still achievable, though with some modification of the

methodology presented.

The author is available for customizing this adaptive CTLE modeling approach as needed.

Summary

This article presented a methodology for creating an adaptive CTLE AMI model for use in any

Channel Simulator compliant with the IBIS 5.0 AMI Standard.

For a defined set of channel and CTLE characteristics, an adaptive feedback control for

selection of the optimal CTLE was created.

The custom adaptive CTLE C++ model was used in an Rx AMI design in SystemVue for

modeling a SerDes system. SystemVue was used to generate the Rx AMI model code and

files. The Rx AMI model was named RxAdaptiveCTLE. Though the model was designed at one

specific data rate and samples per bit characteristic, the modeling methodology enables it to be

usable for other data rates and sample per bit values.

The Rx AMI model was used in the ADS Channel Simulator and is portable for use in any other

channel simulator that is compliant with the IBIS 5.0 AMI standard.

Limitations of the approach used in this article were discussed and solutions were discussed to

overcome those limitations.

Acknowledgment

Thanks to Agilent Technologies, Inc., EEsof Division for providing the SerDes signal integrity

market with their fine line of EDA tools, SystemVue and Advanced Design System. These tools

provide a very effective and efficient process for generating portable AMI models per the IBIS

standard.

Biography

John Baprawski is Systems Engineer with over 35 years designing RF and communications

systems and EDA system design products for the RF, Communications, and High Speed Digital

markets. John was formerly with Agilent EEsof for 22 year as the R&D manager who led the

R&D team for development of system level design tools. Currently, John is a consulting

engineer for modeling high speed digital (HSD) integrated circuits (ICs) based on the industry

Input/Output Buffer Information Specification (IBIS) Algorithmic Model Interface (AMI) standard.



John Baprawski can be contacted through his Web site: http://www.johnbaprawski.com; his

Linked-In Web page www.linkedin.com/pub/john-baprawski/13/725/302; or by email at

[email protected].

http://www.johnbaprawski.com/

http://www.linkedin.com/pub/john-baprawski/13/725/302

mailto:[email protected]

creating an adaptive ctle ami model - john baprawski...jun 25, 2012 · occur in the receiver using...

Documents