DesignCon 2010 Predicting BER with IBIS-AMI: experiences correlating SerDes simulations and measurement Todd Westerhoff, Signal Integrity Software, Inc. [email protected]Adge Hawes, IBM [email protected]Dr. Michael Steinberger, Signal Integrity Software, Inc. [email protected]Kent Dramstad, IBM [email protected]Dr. Walter Katz, Signal Integrity Software, Inc. [email protected]Barry Katz, Signal Integrity Software, Inc. [email protected]
Transcript
DesignCon 2010
Predicting BER with IBIS-AMI: experiences correlating SerDes simulations and measurement Todd Westerhoff, Signal Integrity Software, Inc. [email protected] Adge Hawes, IBM [email protected] Dr. Michael Steinberger, Signal Integrity Software, Inc. [email protected] Kent Dramstad, IBM [email protected] Dr. Walter Katz, Signal Integrity Software, Inc. [email protected] Barry Katz, Signal Integrity Software, Inc. [email protected]
Abstract
The IBIS Algorithmic Modeling Interface (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 Biographies
Todd 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.
Introduction The IBIS Algorithmic Modeling Interface (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 measurements
This 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 analysis Serial 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-AMI IBIS-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, or how little detail is exposed to the user
IBIS-AMI assumptions and terminology Many 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 it possible 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 of the 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 and RX clock recovery.
IBIS-AMI based analysis IBIS-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 and Time-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 simulations only 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 Statistical simulation can be used to approximate Decision Feedback Equalizer (DFE) and clock 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 the circuit’s behavior is generated. The difference is speed – IBIS-AMI based Time-Domain analysis typically runs at a million bits per minute. This form of analysis is suitable for modeling the adaptive behavior of DFE control loops and clock recovery circuitry.
IBIS-AMI models Given 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
The 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 impulse response. This level of modeling is ideally suited to Statistical simulation, but can 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 that represent the output of the receiver’s clock recovery algorithm. This level of modeling 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.
HSSCDR Designers 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 models Developing 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 models
IBM 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 of S 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 Background Complete 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 isolated
Correlating 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 Methodology For 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.
The simulator correlation methodology we used was:
1. Assess the different simulator input / outputs first, determine what can be controlled / compared and how
2. Start with as simple a simulation as possible and add complexity incrementally
3. Correlate after each new behavior is added
4. Add jitter & noise modeling into the analysis only after TX / Channel / RX models were correlated
5. Correlate post-processing & extrapolation algorithms last
Correlation 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 simulator correlation, the goal was to match HSSCDR’s predicted operating margins within 5%.
Simulator comparison Correlation 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.
HSSCDR HSSCDR 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.
The 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 Designer SiSoft’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’s Time-Domain mode most closely resembles HSSCDR, and the QCD results in this study were derived from Time-Domain simulation.
QCD 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 Metrics We 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 QCD
Comparing 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 from 1E-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 results Transmitter Correlation
In 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
These cases revealed an interesting (and unexpected) side-effect – the two simulators have what amount to different output bandwidths. In an extremely low-loss case (i.e. a bare TX die driving a resistor with no parasitics), the two simulators have different behavior many harmonics above the fundamental frequency. The difference in eye frequency behavior is most visible in the eye diagram in Figure 9. The differences occur at frequencies that will never be present in any real-world situation – they will be attenuated out before the signal leaves the transmitter package. Simulation allows us to experiment with idealized cases that can’t be physically realized, and this difference between the two sets of simulation results proved to be interesting but inconsequential.
Different output swing settings were compared between the two simulation environments:
Figure 10: HSSCDR / QCD waveforms for different TX output swings
Different equalization settings were compared between the two environments:
Figure 11: HSSCDR / QCD waveforms for different TX equalization settings
In all of the standalone transmitter cases the correlation between HSSCDR and QCD running IBIS-AMI models was found to be excellent.
Transmitter & Channel Correlation Channel simulators accept S parameter data for channel models, but it’s often the case that different simulators produce different results using the same S parameter data. The next set of test cases added a channel model and the receiver’s analog model (termination network) to the mix. Simulation waveforms (representing the signal at the receiver pad) were plotted from both simulators and compared:
Figure 12: HSSCDR / QCD waveforms at RX pad
The impact of differing simulation bandwidth disappeared, as expected. Correlation between the two sets of simulation results was excellent, indicating that both simulators were evaluating the channel model and the RX termination network in an equivalent manner.
Receiver Correlation Adding the RX algorithmic model to the mix changed the nature of the correlation problem, because a post-equalized waveform wasn’t available from HSSCDR. HSSCDR will produce an eye diagram presenting up to 8192 symbols of data, but this wasn’t enough to ensure statistically significant correlation.
We needed to correlate to the HEYE and VEYE margins reported by HSSCDR’s text output report. These values represent the cumulative timing and voltage margin of the sampled data at the receiver at probability levels down to 1E-15.
The IBIS-AMI receiver models output two pieces of data – the equalized signal at the sampling latch, and clock ticks from simulation of the clock recovery circuit. QCD combines and post-processes these two outputs to create the different outputs from the simulator, as shown in Figure 13.
Figure 13: Deriving eye contours from IBIS-AMI RX models
To isolate the behavior of the RX algorithmic model and test our measurement method, we zeroed out all jitter and noise sources in both simulators. Simulations were run for 1M bits and eye height / width was measured from the QCD contour plots and compared to the values of HEYE and VEYE reported by HSSCDR at 1E-3 and 1E-6 probability levels. We didn’t compare the lower probability data because we weren’t correlating extrapolated behavior at this point.
Correlation between the two sets of results was well within the target correlation range:
Figure 15: Correlation results for channels without noise/jitter
The data shown here is for the Cu065 / HSS6 technology running at 6.25 Gb/s; similar results were obtained for other technologies and speeds.
Jitter & Noise Modeling Simulating 1M bits and predicting at 1E-15 probabilities requires that the simulator combine simulation results, noise budgets and extrapolation to predict operating margins at the target probability levels. Achieving this next level of correlation required examining the jitter and noise modeling capabilities of each simulator and understanding how they contributed to the predicted result.
An overview of HSSCDR’s jitter and noise modeling facility was presented in [4]. :
These jitter and noise sources were mapped into their counterparts and corresponding values in QCD:
Figure 17: Jitter and noise models in QCD
Simulations were run for 1M bits, with results extrapolated to the 1E-15 level. The results were plotted and the eye margins were measured according to the way results are reported by HSSCDR. Each jitter / noise source was first compared and correlated individually, then different jitter & noise sources were simulated and correlated collectively.
The plots below represent the end to end network simulation of a Cu065 HSS10 channel running at 10 Gb/s with a complete set of jitter and noise sources:
Figure 18: Eye distribution for 10Gb/s channel with jitter & noise
Figure 19: Eye contours for 10Gb/s channel with jitter & noise
Note that the eye is mostly closed – we used a legacy channel originally designed for 3.125 Gb/s operation and ran it at 10 Gb/s because it presented a more challenging simulation and correlation exercise. The eye margins for this exercise compared within the target correlation margin (5%). The bathtub curves from both simulators are compared in Figure 20.
Figure 20: HSSCDR / QCD HEYE plots for 10Gb/s jitter / noise case
This represented full correlation between the two simulation environments, including all the modeling, simulation, post-processing and extrapolation factors shown in Figure 5.
Performance One of the original goals of IBIS-AMI was to deliver simulation models for SerDes transceivers that offer the same level of performance as the semiconductor vendor’s proprietary simulator. To test this, we compared simulation run times for our 10Gb/s test case at run lengths ranging from 100K bits to 10M bits:
HSSCDR QCD
100K bits 43 sec 34 sec
1M bit 3 min 48 sec 3 min
10M bits 35 min 4 sec 28 min 50 sec
Figure 21: Simulation performance results
These run times are based on a Dell D820 laptop with two T7200 cores running at 2 GHz, 2GB of RAM, running a single simulation (i.e. using only one of the two cores).
Extending the IBIS-AMI Standard Over the course of the study we identified several areas where the current IBIS-AMI specification could be extended to allow enhanced accuracy and/or improved model transportability:
• Broadband analog models – it is difficult under the current IBIS specification to specify an analog model that has different behaviors at different frequencies, yet this is essential to obtaining the correct impulse response for the analog network. IBM, SiSoft and Cisco proposed enhancements to IBIS-AMI as outlined in [1].
• Standardized jitter / noise modeling – the current IBIS-AMI specification has limited facilities for allowing a semiconductor vendor to supply jitter and noise budgets as part of the model. This effort showed those budgets are essential to achieving correlation and should be considered part of the supplied model. IBM and SiSoft will be proposing extensions to IBIS-AMI in 2010 for this purpose.
Summary We have introduced the IBIS-AMI standard for SerDes transceiver modeling and discussed how it can be used to support simulations of high speed serial links.
IBM’s IBIS-AMI strategy uses a common set of algorithmic models that can be configured to represent different families of SerDes cores. This allows new device families to be modeled quickly and efficiently.
Through the course of our model development and correlation effort, we demonstrated that the combination of IBM’s models and QCD meet the original goals laid out for IBIS-AMI:
• Interoperability – we have successfully simulated IBM’s models in conjunction with IBIS-AMI models from other Semiconductor vendors (we have not presented those results here)
• Transportability – IBM’s IBIS-AMI models have been run in QCD, IBIS-AMI reference platforms, and other EDA tools (we have not presented those results here)
• Performance – IBM’s IBIS-AMI models in QCD offer the same simulation performance as HSSCDR
• Accuracy – IBM’s IBIS-AMI models in QCD produce the same eye margins as predicted by HSSCDR. Note that achieving correlation at lower probability levels is contingent on proper jitter / noise budgeting and extrapolation
[1] IBIS Open Forum, IBIS 5.0 Specification, August, 2008, <http://eda.org/pub/ibis/ver5.0/ver5_0.pdf>
[2] Walter Katz, Michael Steinberger, Todd Westerhoff, “IBIS-AMI Terminology Overview”, DAC IBIS Summit, July 2009
[3] Michael Steinberger, Todd Westerhoff, Christopher White, “Demonstration of SerDes Modeling Using the Algorithmic Modeling Interface (AMI) Standard”, paper 7-TA3, DesignCon 2008
[4] Troy Beukema, “Challenges in Serial Electrical Interconnects at 5 to 10 Gb/s and Beyond”, IEEE SSCS, Fort Collins, CO, March 2007.
[5] Adge Hawes, Doug White, Walter Katz, Todd Westerhoff, “Creating Broadband Analog Models for SerDes Applications”, DesignCon 2009 IBIS Summit, February 2009
![DesignCon 2014 - SiSoft...1 DesignCon 2014 How Design of Experiments Saved my CEI VSR 28G Design Richard Allred, SiSoft [rallred@sisoft.com] Barry Katz, SiSoft Ishwar Hosagrahar, Inphi](https://static.documents.pub/doc/80x56/5f19284848bb9016ff191954/designcon-2014-sisoft-1-designcon-2014-how-design-of-experiments-saved-my.jpg)
