Upload
others
View
0
Download
0
Embed Size (px)
Citation preview
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 1
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
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 2
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:
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 3
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:
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 4
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
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 5
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).
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 6
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
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 7
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
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 8
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.
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 9
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
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 10
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.
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 11
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.
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 12
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.
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 13
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
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 14
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.
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 15
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.
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 16
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.
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 17
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.
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 18
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.
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 19
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.
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 20
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.
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 21
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.
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 22
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
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 23
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"
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 24
#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:
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 25
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:
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 26
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.
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 27
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.
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 28
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:
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 29
#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.
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 30
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.
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 31
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.
Creating an Adaptive CTLE AMI Model 2012
Copyright © 2012 John Baprawski Page 32
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