Predicting BER with IBIS-AMI_eperiences correlating SerDes simulations and measurement

DesignCon 2010Predicting BER with IBIS-AMI: experiences correlating SerDes simulations and measurement Todd Westerhoff, Signal Integrity Software, Inc. twesterh@Adge Hawes, IBMadge@Dr. Michael Steinberger, Signal Integrity Software, Inc. msteinb@Kent Dramstad, IBMDramstad@Dr. Walter Katz, Signal Integrity Software, Inc.wkatz@Barry Katz, Signal Integrity Software, Inc.bkatz@AbstractThe IBIS A lgorithmic M odeling I nterface (IBIS-AMI) allows SerDes vendors to provide simulation models that run in multiple simulation environments. This has created the market for commercial SerDes channel simulators and raised the question of how well IBIS-AMI models correlate to both SerDes vendor internal simulation tools and hardware measurements. This paper presents the results of a three-year effort to develop and correlate IBIS-AMI models for IBM’s family of SerDes cores. The correlation methodology and results for simulator-to-simulator correlations are presented. Author BiographiesTodd Westerhoff, Vice President of software products for SiSoft, has over 30 years experience in the modeling and analysis of electronic systems, including 14 years of signal integrity experience. Prior to joining SiSoft, Todd managed a high-speed design group that provided static timing, signal integrity and design rule consultation to various ASIC and system engineering groups within Cisco. Previously, Todd was the SPECCTRAQuest Product Manager for Cadence Design Systems and a signal integrity consultant to a number of Fortune 500 companies. He has held product marketing positions at Compact Software, Racal-Redac, FutureNet and HHB-Systems. Todd holds a B.E. degree in Electrical Engineering from the Stevens Institute of Technology in Hoboken, New Jersey.Adge Hawes is a Development Architect for IBM at its Hursley Labs, United Kingdom. He has worked for IBM for more than 30 years across such hardware as Graphic Displays, Printing Subsystems, PC development, Data Compression, and High-Speed Serial Links. He has represented the company in many standards bodies such as PCI, SSA, ATA, Fibre Channel and IBIS. He now develops simulators for IBM's High Speed Serial Link customers. He received a BSc (Hons) Electronics from Southampton University (UK) in 1976.Dr. Michael Steinberger is currently responsible for leading the development of SiSoft's serial link analysis products. He has over 30 years experience in the design and analysis of very high speed electronic circuits. Prior to joining SiSoft, Dr. Steinberger worked at Cray Inc., where he designed very high density interconnects and increased the data rate and path lengths to the state of the art. Mike holds a B.S. from the California Institute of Technology and a Ph.D. from the University of Southern California, and has been awarded 13 U.S. patents.Kent Dramstad is an ASIC Application Engineer at IBM. A 1980 BSEE graduate of Iowa State University, he has over 29 years of experience working on both power and signal integrity issues for a wide variety of applications. His current emphasis is on helping customers select and integrate IBM’s series of High Speed Serdes (HSS) cores into their ASIC designs.Dr. Walter Katz, Chief Scientist for SiSoft, is a pioneer in the development of constraint driven printed circuit board routers. He developed SciCards, the first commercially successful auto-router. Dr. Katz founded Layout Concepts and sold routers through Cadence, Zuken, Daisix, Intergraph and Accel. More than 20,000 copies of his tools have been used worldwide. Dr. Katz developed the first signal integrity tools for a 17 MHz 32-bit minicomputer in the seventies. In 1991, IBM used his software to design a 1 GHz computer. Dr. Katz holds a PhD from the University of Rochester, a BS from Polytechnic Institute of Brooklyn and has been awarded 5 U.S. Patents.Barry Katz, President and CTO for SiSoft, founded SiSoft in 1995. As CTO, Barry is responsible for leading the definition and development of SiSoft’s products. He has devoted much of his efforts at SiSoft to delivering a comprehensive design methodology, software tools, and expert consulting to solve the problems faced by designers of leading edge high-speed systems. He was the founding chairman of the IBIS Quality committee. Barry received an MSEE degree from Carnegie Mellon and a BSEE degree from the University of Florida.IntroductionThe IBIS A lgorithmic M odeling I nterface (IBIS-AMI) provides a standardized way of modeling the behavior of multi-Gigabit SerDes transceivers for serial link simulations. The first question users ask about any new simulation model is usually “is it accurate?” To provide an objective and meaningful answer, it’s important to qualify exactly what constitutes acceptable accuracy and how it is measured.IBIS-AMI models are typically compared to two different references:•Simulation results from other simulation tools•Hardware measurementsThis paper describes the process used to develop and correlate IBIS-AMI models for IBM’s family of High Speed SerDes (HSS) transceiver cores. In practice, answering the question “is it accurate?” requires defining a set of specific correlation test cases, metrics and criteria. The correlation metrics need to be defined based on the reference source (hardware measurement or other simulator) and based on which aspects of device behavior can be reliably controlled and observed.SerDes analysisSerial link simulation requires different tools and techniques than traditional parallel interface signal integrity analysis. Serial links typically look to achieve bit error rates of fewer than 1 in every 1E15 bits. Predicting operating margins at these low probability levels requires simulating a million bits (or more) to adequately characterize the effects of Duty Cycle Distortion (DCD) and Inter-Symbol Interference (ISI). Simulation results are post-processed to account for the effects of different noise and jitter sources, which allows prediction of operating margins at very low probability levels.IBM’s High Speed SerDes / Clock Data Recovery (HSSCDR) simulator is a proprietary MATLAB based system-level signal integrity simulator that support’s IBM’s HSS cores. HSSCDR uses behavioral models of the IBM HSS I/O circuits along with S parameter descriptions of the individual components in the serial data path to provide a very fast, robust means of predicting signal quality on high-speed channels. HSSCDR provides greatly reduced simulation times compared to extracted element models (such as HSPICE). HSSCDR can also provide optimized control settings (pre-emphasis, output power, receiver amplification, receiver equalization, etc.) for peak signal quality performance with different customers’ individual link characteristics.IBM correlates HSSCDR simulations against hardware measurements for each new generation of HSS cores to ensure that simulations correctly predict the behavior exhibited by the hardware. This allows customers building serial links using IBM ASICs to predict the behavior of a proposed system implementation before manufacture, adjusting both the system design and SerDes settings to optimize operating margin. This process works well when IBM silicon is employed at both ends of the link, but what happens when another vendor’s silicon is used on one end of the link?HSSCDR is a dedicated simulation environment based on IBM technology; there are no provisions for plugging a model for another vendor’s silicon into HSSCDR. That’s where IBM’s IBIS-AMI models come into play.IBIS-AMIIBIS-AMI is part of the IBIS 5.0 standard and defines a method for modeling SerDes analog I/O characteristics, equalization and clock recovery behavior. IBIS-AMI was developed by a consortium of EDA, Semiconductor and Systems companies beginning in 2006 and was adopted as part of IBIS 5.0 in August, 2008.The design goals established for IBIS-AMI were:•Interoperability – Models from different semiconductor vendors run together in the same simulation•Transportability – The same model runs in different simulators•Performance – IBIS-AMI based simulation should provide comparable performance to a semiconductor vendor’s proprietary simulator •Accuracy – IBIS-AMI based simulations should provide results comparable to those obtained with proprietary semiconductor vendor tools•IP Protection – Semiconductor vendors need to be able to provide accurate models of their devices without divulging internal architectural details.IBIS-AMI models must allow semiconductor vendors to control how much, orhow little detail is exposed to the userIBIS-AMI assumptions and terminologyMany channel simulators (HSSCDR included) accept a model for the serial channel as S parameter data. The channel can be described as a single S parameter block or as a cascaded set of blocks, but in either case, the user input to the simulator represents the passive (unpowered) portion of the channel. The models for the transmitter’s equalization and output driver, receiver termination network, receiver equalization and clock recovery have traditionally been built directly into the channel simulator.IBIS-AMI makes the assumption that transmitter equalization is electrically isolated (buffered) from the channel, such that variations in channel loading don’t affect the input signal presented to the transmitter’s output driver. The same assumption is made at the receiver – changes in equalization or clock recovery behavior don’t affect the input signal at the receiver die pad.The IBIS-AMI specification states this assumption using the following language:“The transmitter equalization, receiver equalization and clock recovery circuits are assumed to have a high-impedance (electrically isolated) connection to the analog portion of the channel. This makes itpossible to model these circuits based on a characterization of the analog channel.”IBIS-AMI treats the analog channel as linear and time-invariant (LTI). The analog channel is “characterized” using circuit analysis techniques, and that characterization data (in the form of an impulse response) is combined with models of the SerDes equalization and clock recovery behavior to predict the overall behavior of the link.The assumption that the analog channel can be characterized is key to increasing simulation speed and being able to simulate the millions of bits needed to predict serial link behavior.IBIS-AMI uses the following terms to describe portions of a serial link:Figure 1: IBIS-AMI passive channel•The passive channel is defined as all the passive, unpowered interconnect between the transmitter and receiver pads. This includes device packages, vias,PCB etch and cables.Figure 2: IBIS-AMI analog channel•The analog channel combines the passive channel with the transmitter’s analog output section and the receiver’s input termination network. This is the part ofthe link that is assumed to be electrically isolated from the equalization and clock recovery circuitry.Figure 3: IBIS-AMI end to end channel•The end to end channel combines the analog channel (represented as an impulse response) with algorithmic models for TX / RX equalization andRX clock recovery.IBIS-AMI based analysisIBIS-AMI simulation occurs in two stages: Network Characterization and Channel Simulation.Network Characterization uses circuit analysis techniques to characterize the analog channel and derive its impulse response. Network Characterization uses a model of the passive channel and models of the SerDes TX / RX analog characteristics to perform this analysis.Channel Analysis takes the impulse response created by Network Characterization and uses Algorithmic Models for the TX / RX equalization and clock recovery to simulate the link’s end to end behavior. Channel simulators are a new breed of tool - they don’t perform circuit analysis the way SPICE does. Instead they use communications analysis techniques (data sampling, interpolation & convolution) to perform Statistical andTime-Domain simulation.Channel Analysis comes in two forms:•Statistical simulation produces an eye diagram showing the probabilities of signal distribution at the receiver, but doesn’t use a specific stimulus sequence.Statistical analysis has the advantage of being very fast (individual simulationsonly take a second or so), but makes the assumption that the TX / RX equalization behavior is linear and time-invariant. In practice, this means that Statisticalsimulation can be used to approximate Decision Feedback Equalizer (DFE) andclock recovery behavior, but more detailed models are needed to fully validate the link’s behavior.•Time-Domain simulation behaves much like traditional SPICE-based analysis in the sense that an input stimulus is applied and a waveform representing thecircuit’s behavior is generated. The difference is speed – IBIS-AMI basedTime-Domain analysis typically runs at a million bits per minute. This form ofanalysis is suitable for modeling the adaptive behavior of DFE control loops andclock recovery circuitry.IBIS-AMI modelsGiven that IBIS-AMI based simulation occurs in two stages, it should come as no surprise that IBIS-AMI models are supplied in two parts – an analog model used for Network Characterization and an algorithmic model used for Channel Analysis. The combination of these two models represents the complete behavior of the device.The analog portion of an IBIS-AMI model contains the information a simulator needs to determine the impulse response for the channel when equalization is turned off. From a practical standpoint, the elements of the analog model are:•Transmitter: output voltage swing, impedance, slew rate, output parasitics•Receiver: input termination network impedance & parasiticsThe algorithmic model is a behavioral model supplied as executable code that gets linked into the channel simulator at run time. IBIS-AMI defines the calling interface between the simulator and the model linked into it. Providing models as executable code maximizes simulation speed, which was one of the design goals for IBIS-AMI.IBIS-AMI algorithmic models can support two different levels of processing: •Impulse response processing – an impulse response is passed to the algorithmic model, which applies its equalization and passes back a modified impulseresponse. This level of modeling is ideally suited to Statistical simulation, butcan also be used for Time-Domain simulation.•Waveform processing – a waveform is passed to the algorithmic model, which applies its equalization and passes back a modified waveform. If the algorithmic model represents a receiver, the model can also pass back clock ticks thatrepresent the output of the receiver’s clock recovery algorithm. This level ofmodeling can only be used by Time-Domain simulation.Algorithmic models are accompanied by a text control (.AMI) file that tells the channel simulator which processing modes the model supports and lists any model-specific control parameters. Model-specific control parameters allow users to configure the behavior of the model to emulate the way the hardware is programmed.HSSCDRDesigners simulate their channels in HSSCDR by providing an S parameter model of their channel from package pin to package pin. HSSCDR includes models for IBM’s SerDes cores and device packages. Users specify which device technology is to be used and how hardware options are to be configured, and HSSCDR provides simulation results for how IBM’s devices with work with the customer’s channel.HSSCDR performs high-performance Time-Domain simulation, with a throughput of about 500K bits/minute. Simulation results are post-processed to account for the effects of TX / RX jitter and other random noise sources. Statistical post-processing & extrapolation are performed automatically, predicting link operating margins at probability levels down to 1E-15 based on simulation runs of 1M bits.IBM’s IBIS-AMI modelsDeveloping models for all the SerDes cores represented in HSSCDR is a daunting task – HSSCDR currently supports more than 17 different sets of SerDes cores implemented across 5 different process nodes. Models for IBM’s SerDes cores are referenced in HSSCDR by speed and process node. Control files in HSSCDR configure the simulation algorithms built into the simulator for the technology being modeled.IBM’s strategy for developing IBIS-AMI models mirrors the way HSSCDR operates. A central set of modeling algorithms is implemented in a common set of algorithmic models, which use configuration data specific to each speed and process node to configure themselves. The .AMI control file supplied with IBM’s algorithmic models supplies the data for this task.The .AMI file configures the algorithmic model to provide the correct number of equalization taps for the technology being modeled, sets the maximum limits for each tap and configures the capabilities of the receiver’s Automatic Gain Control (AGC) and DFE behavior. The .AMI file declares the sensitivity of the receiver’s sampling circuit, so the simulator can determine whether enough voltage has been developed at the sampling point to allow error-free operation.The models also use the .AMI file to declare model parameters users can control through the simulator’s graphical interface. The names and settings of these parameters correspond as closely as possible to their HSSCDR equivalents, allowing existing HSSCDR users to leverage their existing settings for IBIS-AMI use.Figure 4: Control parameters exposed by IBM IBIS-AMI modelsIBM characterizes the transmitter analog output and receiver termination network over a wide frequency range to determine signal transmission and reflection characteristics. IBM captures this information in S parameter format and HSSCDR uses this data to model how the analog portions of the transmitter and receiver interact with the channel. The IBIS 5.0 specification provides methods for modeling analog I/O that have worked well for lower speed parallel interface applications, but which don’t capture the frequency-dependent behavior needed for serial link analysis. The results presented in this paper are based on using IBM’s on-die S parameter data to provide the analog model characteristics. Extending the current IBIS-AMI specification to allow use ofS parameter data has been proposed as an extension to IBIS-AMI by IBM, SiSoft and Cisco. More information on this proposal can be found in [5].Correlation BackgroundComplete correlation between simulators or between simulation and hardware is an obvious goal, but determining what level of correlation is acceptable, and under what conditions – is essential to success. 100% correlation between any two channel simulators is highly unlikely, and perfect correlation to hardware measurement is impossible, because even two repeated hardware measurements can’t be expected to match precisely.To be able to achieve correlation, one must define:•What is going to be compared to what?•Under what conditions?•What can be controlled & what can’t?•What metrics will be used and what level of correlation is expected?It’s also important to note that correlating simulator to simulator and simulator to hardware are two different activities. Correlating simulation to hardware presents one set of challenges:•Observability at the SerDes sampling latch is limited and depends on the receiver in question•Controllability (stimulus, ability to set tap coefficients, etc) depends on the hardware under test•Some behaviors (random jitter, etc) can’t be controlled or isolatedCorrelating between simulation environments presents a different set of challenges: •Different simulators will have different inputs and outputs•Post-processing & extrapolation details are simulator-specific (and in the case of HSSCDR, proprietary)Correlation MethodologyFor this project, correlation between simulators was pursued first because the results from each simulation tool were repeatable and because HSSCDR has already been extensively correlated to hardware. It might seem that correlating two simulators would be straightforward – running simulations in both tools and comparing the resulting waveform output. In actual practice, running million bit simulations and comparing waveforms proved to be neither practical nor particularly insightful.The end goal of the IBIS-AMI correlation effort was to reproduce the horizontal (timing) and vertical (voltage) eye margins as reported by HSSCDR. We identified all the different model elements, simulation and post-processing that factor into this computation (Figure 5) and defined a process that would allow us to correlate all of these factors in a controlled manner.Figure 5: Factors in computing eye marginsThe simulator correlation methodology we used was:1.Assess the different simulator input / outputs first, determine what can becontrolled / compared and how2.Start with as simple a simulation as possible and add complexity incrementally3.Correlate after each new behavior is added4.Add jitter & noise modeling into the analysis only after TX / Channel / RXmodels were correlated5.Correlate post-processing & extrapolation algorithms lastCorrelation of IBIS-AMI models to hardware measurement is the next stage of this project; publishable results were not available at the time this paper was written.IBIS-AMI to hardware correlation will follow the same path IBM uses to correlate HSSCDR to hardware. This approach leverages hardware measurements and correlation data IBM already has available.In all cases, correctly setting expectations is key to success. For simulator to simulatorcorrelation, the goal was to match HSSCDR’s predicted operating margins within 5%.Simulator comparisonCorrelation would be easier if both simulators had the same inputs and outputs, but they don’t. Channel simulators are their own breed of tool; since they simulate millions of bits worth of information, they necessarily accumulate, post-process and summarize data for presentation.HSSCDRHSSCDR takes a channel model as input, specified as S parameter data. The user specifies the data rate, input pattern type, device technology (e.g. Cu045 HSS12), package selection and other settings via a graphical interface. Simulation models for the different IBM technologies and packages are supplied as part of HSSCDR. When the simulation is complete, the GUI presents a collection of plots (Log BER, Impulse Response, Transfer Function, Eye Diagram & Eye Height) that display results from the simulation.Figure 6: HSSCDR OuputsHSSCDR also provides a text output report that lists eye margins at different probability levels. A section of this report is shown below:HMIN -37.5% HMAX 34.0% HEYE 68.1% 10^-3HMIN -37.5% HMAX 32.8% HEYE 65.6% 10^-6HMIN -37.5% HMAX 32.8% HEYE 65.6% 10^-9HMIN -37.5% HMAX 32.8% HEYE 65.6% 10^-12HMIN -37.4% HMAX 32.8% HEYE 65.6% 10^-15BER FLOOR = 1.0e-300VMIN 64.7% VMAX 125% VEYE 65.8mV 10^-3VMIN 63.2% VMAX 129% VEYE 64.2mV 10^-6VMIN 62.9% VMAX 129% VEYE 63.9mV 10^-9VMIN 62.8% VMAX 130% VEYE 63.8mV 10^-12VMIN 62.6% VMAX 130% VEYE 63.6mV 10^-15Figure 7: HSSCDR text output reportThe text report proved to be the best metric for comparing simulation results for the end to end channel, because it represented the simulation data accumulated over the entire simulation run and included the projected effects of jitter and random noise over large numbers of patterns. Remember that the channel simulator is typically only simulating millions of bits, while a typical target channel bit error rate might be 1 in every 1E15 bits or more. Predicting link margins requires combining simulated data with extrapolated data to predict link margins at the probability levels the user ultimately cares about. HSSCDR also records “raw” waveform data to a binary file, which can be displayed in a waveform viewer. The challenge is that the “raw” waveform data doesn’t include the effects of RX equalization and clock recovery. Thus, the “raw” waveform data is useful for correlating everything up to the RX pad, but not for correlating past that point in the channel.The HSSCDR outputs used for this study are outlined in red in Figure 6.Quantum Channel DesignerSiSoft’s Quantum Channel Designer (QCD) is a commercial channel simulator that can use either HSPICE or IBIS-AMI models for simulation. In this study, the IBM transmitter and receiver were supplied as IBIS-AMI models.The channel model to be analyzed in QCD is captured graphically, and can consist of a mixture of S parameter blocks, lossy transmission lines, SPICE subcircuits and individual R/L/C elements. The user specifies the stimulus pattern, data rate & model control parameters via the graphical interface.In this study, the same S parameter channel and package data was used in both simulators.Quantum Channel Designer has two simulation modes: a Statistical simulation mode that uses convolution techniques to analyze the effects of very large populations (>10**100) of random bit sequences, and a Time-Domain simulation mode that analyzes the effects of specific input sequences. Statistical simulation requires linear (impulse response processing) models for transmit / receive equalization, while Time-Domain simulation makes use of non-linear, time-varying (waveform processing) models. QCD’sTime-Domain mode most closely resembles HSSCDR, and the QCD results in this study were derived from Time-Domain simulation.Figure 8: Quantum Channel Designer (QCD) output plotsQCD provides a collection of output plots, including impulse / pulse / step responses, waveform plots, eye diagrams, data bathtub & clock PDF plots, network transfer functions and eye plots color coded to show signal distribution. QCD also computes and displays a number of metrics, including channel & reflection loss, projected BER, and eye height / width at a number of different probability levels. The QCD outputs used for this study are outlined in red in Figure 8.Correlation MetricsWe needed data from the two different simulation environments that could be readily compared and was also statistically significant. After analyzing the different outputs from each tool, we defined the following basis for comparison:•“Raw” waveform data from HSSCDR could be compared against waveform plots in QCD to correlate everything up to and including the RX pad•The HEYE / VEYE margin data from HSSCDR’s text output report could be compared against the corresponding Contour Plot measurements from QCDComparing the “raw” waveform data from HSSCDR against waveforms produced in QCD is a direct method and has the advantage that many data points (the voltage of the signal at each point in time) are available for comparison. It’s easy to overlay waveforms and assess the quality of the result, and it’s usually obvious when something is wrong. Comparing eye voltage and timing margins from simulation is an indirect method, requiring the simulator to first combine the simulated data & recovered clock behavior to derive eye statistics and contours, then measuring the eye height and width. The conundrum with this measurement is that although many bits are represented, the number of actual data points for comparison is small. We measured at probability levels from1E-3 to 1E-15, providing 5 data points each for voltage and timing margin. With fewer data points for comparison, more simulations and channels needed to be studied to ensure the consistency of the results..We created a set of test cases that started as simple as possible and allowed us to introduce and correlate new behaviors in a controlled fashion. We zeroed out the effects of jitter & noise until after we were sure we had the transmitter / channel / receiver modeling correlated.As these simulations were something we expected to repeat many times before the study was done, we automated as much of the process as possible.Correlation cases and resultsTransmitter CorrelationIn all of the waveforms that follow, the blue waveforms show HSSCDR results and the red waveforms show QCD results. The IBM waveforms are “in front” – where the red waveforms aren’t visible, they’re completely hidden behind the HSSCDR results.The first (and simplest) test cases consisted of a transmitter driving directly into a resistive load without a package model. Using such a simple test case allowed us to correlate drive levels, slew rates and equalization characteristics of the transmitter model directly.Figure 9: HSSCDR / QCD waveforms for simple TX case。