Designers of switch fabrics for communications and networking equipment face many choices today in determining the performance of their systems. Continuing demand for higher data throughput--up to 2.5 Gbit/s and 10 Gbit/s--bumps up against constraints in technology, not to mention cost and time to market considerations. Achieving high performance with adequate signal integrity is an exercise in tradeoffs between different architectures and components. The designer's decisions have to be based on understanding the constraints involved, the technologies available, and the adequacy of the simulation and modeling tools.
Most notably, faster edge rates have caused high-performance systems to become more susceptible to noise at higher speeds. Switching in the sub-nanosecond range creates a volatile environment within transmission lines and power distribution networks. Electromagnetic interference, reflections, and power-supply switching demands all have an impact on how fast the signal can switch.
Designers are increasingly forced to consider moving to serial point-to-point differential I/O over parallel single-ended multidrop I/O to achieve higher throughput while managing costs and power consumption. But in doing so, they confront several signal integrity issues that have not been apparent at slower switching speeds or with which they have had little experience.
LVDS (Low Voltage Differential Signaling) is emerging as the serial I/O technology of choice in communications systems because they offer the advantage of very high speed--up to 40 Gbit/s--with reduction in bus width and power.
For high-speed differential signaling, the issues include the type of termination used, trace routing, the quality of the power planes and distribution network, and the selection of components with a minimal amount of lead inductance. Even the vias can impact signal integrity for signals with sub-nanosecond edge rates.
To the decisions mentioned earlier might be added a less obvious criterion: having a component-supplier partner that is knowledgeable in the details of I/O interfaces and the elements of designing for signal integrity. This is an area that Fairchild Semiconductor's Ensigna Lab has focused on and developed a deep understanding of the technologies and tradeoffs necessary.
Achieving adequate signal integrity is not limited to a few items. It is, in fact, an interconnected flow of events and technologies that define the performance of the system.
Marketing requirements define the basic characteristics of the system to start with: what costs will be incurred, what is the nature of the data being transported, and what components will be chosen. The system architecture is developed to meet these requirements. But timing and signal integrity simulations are not easily designed in at this point without accurate simulation results of the components.
In the past signal integrity analysis was often done after the layout, or place-and-route, stage because many designers simply did not have the expertise in signal integrity or the tools required to design in earlier stages. It follows that this requires prototyping on the part of the system house, with several iterations often being necessary.
But today's rapid design cycles make that practice more and more unrealistic. Companies can no longer afford to build and optimize prototypes multiple times while working with incomplete modeling information.
To keep the process from becoming one of trial and error, an additional level of assistance from the component vendor can save the customer many iterations, by knowing which parameters are most likely to make the optimum tradeoffs necessary. When knowing these tradeoffs the designer can then simplify the process through targeted simulation. Of course, simple and accurate models are the backbone to successful simulation.
IBIS (I/O Buffer Information Specification) models have become an important signal-integrity simulation tool as more designers prefer the easy access to and simplicity of these models. IBIS models are often used in place of SPICE models because they are smaller in file size, easier to transport, are several orders of magnitude faster to run and because IC vendors are more willing to release IBIS models of their devices, as they do not reveal proprietary information. In addition, simulations with IBIS models are more likely to converge than simulations with SPICE models due to the sheer complexity of SPICE models.
IBIS models were originally developed for single-ended TTL-based I/O technologies. The accuracy of the single-ended models have vastly improved over the years. However, IBIS models (generated using the same techniques as TTL-based I/O) for simulating differential LVDS driver and transceiver ICs have proven to be less accurate and unreliable predictors of circuit performance.
This paper presents the results of research performed by Fairchild Semiconductor's Ensigna Lab describing a new methodology for creating accurate LVDS IBIS models primarily by employing a constant voltage between device outputs.
LVDS IBIS models can be verified as accurate by determined by how well the model correlates to the source LVDS HSPICE model it was derived from. Transient analysis within HSPICE of both the LVDS HSPICE and LVDS IBIS models are conducted under identical conditions to see how well the LVDS IBIS models correlate to the source HSPICE models.
To illustrate this technique, the EnSigna Lab has modeled Fairchild's FIN1017 and FIN1101 drivers and FIN1018 receiver within the IBIS specification and simulated in HSPICE.
Standard Methods of Gaining Data for IBIS datasheets
An IBIS model of an LVDS device generated using the standard techniques of IBIS data generation would fail to accurately represent the LVDS device when used in simulation.
Described simply, an IBIS model is a collection of DC (current v. voltage) and transient (voltage vs. time) data taken from the device being modeled. This data can be collected through either laboratory measurement or by simulation of the SPICE model representing the device. Once created, the IBIS model can then be used by EDA tools to create a behavioral model of that device. The behavioral modeling process is proprietary to the EDA tool, and is based on the information contained in the IBIS model itself.
If one were to generate an IBIS model of an LVDS device using the standard techniques of IBIS data generation, then this model would fail to accurately represent the LVDS device when used in simulation. Let's briefly examine these standard techniques so that later they can be further examined in comparison to non-standard techniques to better our understanding of why they are invalid when modeling LVDS driver technologies.
The standard, well-worn method of gaining data for IBIS models through SPICE simulation is known as SPICE-to-IBIS translation. To understand why this translation is not accurate in all instances, compare the output-buffer IBIS data of two drivers: one a typical TTL driver, and the other an LVDS driver.
For this example, let us assume that both the TTL and LVDS devices have output buffers such that they cannot be disabled to a high impedance state. Therefore by the IBIS specification, this type of output buffer is recommended to be modeled with the following I/V and V/t data: a pullup curve, a pulldown curve, two rising waveforms, and two falling waveforms. Once this data is collected, it will be formatted and included in the IBIS model representing the respective TTL and LVDS devices. (In this sense, an IBIS model can be more accurately described as an IBIS datasheet, but here it will be referred to as an IBIS model.)
Data for Output Buffers: I/V Data Pullup and Pulldown Curves
The pullup curve is defined by the I/V characteristics of the output buffer when it is fully in the logic high state, and the pulldown curve describes the I/V characteristics of the output buffer when it is fully in the logic low state. The device is driven to a full high state for pullup, or full low state for pulldown, and a DC voltage source on the output node of the device is then swept from --Vcc to 2Vcc. For each incremental voltage step, the corresponding current at the output is measured, thereby gaining a current-vs.-voltage curve representing the I/V characteristics of the device when it is in either the full-on state or full-off state. Combined, this DC data will define the DC output levels of current and voltage of the output buffer being modeled, as well as model the nonlinear output resistance characteristics of the device. Below is the schematic describing the simulation conditions necessary to gain pullup and pulldown data. Corresponding to the schematic are plots of pullup and pulldown curves.
Figure 1. Schematic describing standard simulation conditions for gaining Pullup and Pulldown data
Figure 2. Plots showing Pulldown Curves
Figure 3. Plots showing Pullup Curves
The Rising and Falling Waveform data describe the V/t characteristics of the output buffer. Ultimately this V/t data will be used to model the shape of the rising and falling edges of the output buffer as it switches from the low to high, and from the high to low states. It is also used to determine output current and voltage during these transitions. For TTL output buffers, it is recommended that two sets of rising and falling waveform data be included in the IBIS datasheet. One set of rising and falling waveform data is gained with the output tied to a 50-ohm resistor in series with a voltage source equal to Vcc, and the other set with the output tied to a 50-ohm resistor tied to ground.
For rising waveforms an appropriate ramped input stimulus is used to drive the output to a high state and for falling waveforms an appropriate ramped input stimulus is used to drive the output to a low state. This will produce four V/t waveforms in total--two rising and two falling--which will collectively model the shape of the rising and falling edges over a range of conditions in simulation. The output voltage levels defined in the V/t data should correlate to the output voltage levels as defined in the DC pullup and pulldown data.
Figure 4. Schematic describing standard simulation conditions for gaining Rising and Falling Waveform to Vcc data (note: polarity is inverting)
Figure 5. Schematic describing standard simulation conditions for gaining Rising and Falling Waveform to GND data (note: polarity is inverting)
Figure 6. Plots showing Rising Waveforms (note: polarity is inverting)
Figure 7. Plots showing Falling Waveforms (note: polarity is inverting)
Together, the I/V and V/t data as represented in the plots above is enough information for EDA tools to generate a behavioral model of the output buffer that is suitable for signal integrity simulations.
Improved Methods of Gaining Data for IBIS Datasheets
Unlike a single-ended TTL driver, which drives a signal with one output the differential LVDS driver has two outputs--inverting and non-inverting--driving two signals that collectively act as one. The important point here is that LVDS inverting and non-inverting outputs are dependent upon one another. The output of a TTL driver is not directly dependent on other outputs that may be in the device. Therefore, when gaining data to model a TTL output buffer within the IBIS specification, it is not necessary to take into account other outputs that may be included in the device.
Contrary to this, the LVDS device includes an internal circuitry relating the inverting and non-inverting outputs such that they will always attempt to maintain a constant voltage of 2V(OS) between the outputs as the output voltages vary. Typically, V(OS) is 1.25V. For example, when the non-inverting output of a LVDS device has an output voltage of 1.5V, then through compensation by internal circuitry of the device the voltage at the inverting output will attempt to reach 1.0V such that the sum of voltages between the outputs is equal to 2V(OS).
Since the I/V and V/t characteristics of the inverting and non-inverting outputs of the LVDS driver are dependent upon each other, it is important to gain I/V and V/t data of these buffers where they are behaving naturally in their interdependent environment. That is, the I/V and V/t data gained for LVDS outputs must be done so in an environment where the interdependence of the inverting and non-inverting output buffers is maintained. One cannot gain the I/V and V/t data of an LVDS output while ignoring that output's inverted partner. The data will not accurately represent the I/V and V/t characteristics of that output since its relationship to the opposite output is not accounted for. One must incorporate the effect of the opposite output when gaining data for the other output. This is accomplished with the use of a dependent source during the simulations used to gain the required data for an IBIS model of an output buffer.
Consider the task of gaining I/V data for the non-inverting output of an LVDS device. As previously described, the output is put into either a full-high state or full-low state, then a DC voltage source placed on the output is swept incrementally and the corresponding currents are measured. The problem here is that as this DC sweep is conducted the sum of the voltages between the outputs will not sum to 2V(OS) because the inverting output is being ignored. Therefore, the device is not operating in its natural state and the resulting I/V data cannot be relied upon to be accurate.
Below are two schematics describing standard simulation conditions applied to an LVDS driver to gain DC IBIS data. Corresponding to the schematics are plots which include the DC voltage sweep on the output being modeled, the associated voltages of the non-inverting and inverting outputs as the sweep is performed, and their sum. These plots are included to show how the voltage between the outputs of an LVDS driver does not stay constant during standard simulation conditions for IBIS data collection.
Here the DC sweep is performed while the LVDS driver is terminated:
Figure 8. Standard DC sweep is performed while the LVDS driver is terminated
Figure 9. Plot of output voltages and their sum as standard DC sweep is performed, terminated
Here the DC sweep is performed while the LVDS driver is non-terminated:
Figure 10. Standard DC sweep is performed while the LVDS driver is non-terminated
Figure 11. Plot of output voltages and their sum as standard DC sweep is performed, non-terminated
The sum of the voltages between the inverting and non-inverting outputs do not sum to 2V(OS) as the DC sweep is performed on the non-inverting output buffer of the LVDS device in either case.
Research from the Ensigna Lab shows that this problem can be overcome with the use of a dependent source designed to be a function of the DC voltage source being swept on the output being modeled. In this case, data is being gained for the non-inverting output of the LVDS device, so a dependent voltage source should be put on the output of the inverting output such that a constant voltage equal to 2V(OS) can be maintained between the inverting and non-inverting outputs during the DC voltage sweep. In this way, the I/V and V/t characteristics of the output buffer being modeled will be representative of the device's actual I/V characteristics since the device is operating within it's 'natural' environment.
Here the DC sweep is performed while the LVDS driver has a dependent voltage source on the output not being modeled. This is done so that the voltage between the outputs stays constant as the DC voltage sweep is performed.
Figure 12. Ensigna Lab method DC sweep is performed including dependent voltage source
The following plot shows the DC sweep on non-inverting output, the corresponding output voltage at the inverting output, and the sum of the voltages between both outputs. It can be seen in this plot that the voltages of the inverting and non-inverting outputs now sum to 2V(OS) as the DC sweep is performed on the non-inverting output of the LVDS device.
Figure 13. Plot of output voltages and their sum with the Ensigna Lab method DC sweep is performed, including dependent voltage source
Designing and instantiating a dependent voltage source can be readily accomplished in HSPICE by utilizing the polynomial voltage controlled voltage source. Dependent voltage sources can be implemented in most EDA tools.
As described, the purpose of implementing a dependent voltage source is to maintain constant voltage equal to 2 V(OS) between the outputs. The polynomial can be derived from this expression
(VOUT1 + VOUT2)/2 = 1.25V = V(OS)
where VOUT1 and VOUT2 are the output voltages of the non-inverting and inverting outputs respectively. Solving for either VOUT1 or VOUT2 will define the dependent one-dimensional polynomial voltage source needed.
Therefore, once solved for we would like our polynomial to be the following
VOUT2 = 2.5 - VOUT1
where VOUT2 is now the dependent voltage source being swept in conjunction with the DC voltage sweep on the output buffer being modeled. In other words, the dependent voltage source will always be equal to the negative value of VOUT1 being swept plus 2.50V. In this way, a constant voltage of 2.50V is maintained between the outputs of the LVDS driver as the DC voltage sweep is performed.
Below is HSPICE syntax for the voltage controlled voltage sources for use on inverting and non-inverting outputs of a LVDS driver. For obtaining data from the non-inverting output place the following dependent source on the inverting output.
EV2 DON GND POLY(1) DOP GND 2.5 -1
For obtaining data from the inverting output place the following dependent source on the non-inverting output.
EV2 DOP GND POLY(1) DON GND 2.5 -1
Below are plots comparing I/V and V/t data gained from an LVDS driver using both the standard techniques described above and the improved Ensigna Lab technique of employing a dependent voltage source on the output buffer not being modeled. The differences are quite significant.
Figure 14. Pullup Comparison
Figure 15. Pulldown Comparison
It is also important to employ the use of the dependent voltage source when gaining Vt IBIS data. Below is a schematic describing the use of a dependent voltage while gaining Vt IBIS data, and plots comparing the differences in Vt data gained with both standard and Ensigna Lab methods.
Figure 16. Schematic describing the use of a dependent voltage source when gaining Vt data
Figure 17. Plot comparing Rising Waveform data gained with both the standard and Ensigna Lab methods
Figure 18. Plot comparing Falling Waveform data gained with both the standard and Ensigna Lab methods
A Comparison of LVDS IBIS Models Generated with Both Standard Methods and Ensigna Lab Techniques
Standard and Ensigna Lab LVDS IBIS models are simulated in HSPICE test environments. Their differences will be shown and explained in relationship to the standard and Ensigna Lab methods of LVDS IBIS model creation.
The appropriate data has now been gained to model the LVDS driver device by collecting the data into a IBIS model. Three IBIS models are constructed and compared to each other--two generated with standard techniques and one generated with the Ensigna Lab technique. In the case of the LVDS IBIS models defined by standard-method data, the model does not correlate well to its source HSPICE model. Finally, the LVDS IBIS model gained through the Ensigna Lab method correlates well to its source HSPICE model.
In theory, if one is generating IBIS models by obtaining data from HSPICE simulation, then, at best the IBIS model can only be as accurate as the source HSPICE model itself. For this reason, the verification of the LVDS IBIS model as being accurate will be determined by how well it correlates to the source LVDS HSPICE model it was derived from. Transient analysis within HSPICE of both the LVDS HSPICE and LVDS IBIS models is conducted under identical conditions to see how well the LVDS IBIS models correlate to the source HSPICE model.
Below are the simulation results for all three completed IBIS models. The simulations were performed in HSPICE in a driver-receiver pair configuration connected by bench-correlated transmission-line models and a 100-ohm termination.
Superimposed over the IBIS simulation results are the simulation results for the source LVDS HSPICE driver and receiver models in the same configuration. These results are superimposed to display the accuracy or inaccuracy of the IBIS models in simulation.
Figure 19. environment
Figure 20. Terminated Correlation
Figure 21. Standard Correlation
The above plots demonstrate that using standard methods of IBIS data collection to represent an LVDS driver within the IBIS specification is not successful when correlated to the source HSPICE model of the LVDS driver. The more prominent points to note are the differences in V(OD) and V(OS). It can be seen that V(OS) has been DC-shifted to a level outside the device's specifications in the first plot. Also, V(OD) is too low for both cases and is also outside the device's specifications.
The reason why the IBIS models of the LVDS driver generated with standard techniques failed to produce an accurate representation of DC output voltage levels of the device can be found in the model's pullup and pulldown data. As previously described the I/V characteristics of these outputs are interdependent and since the pullup and pulldown data for these outputs were gained using standard methods, the data does not reflect the interdependent relationship.
Here are the simulation results for the IBIS model of the LVDS driver generated through the Ensigna Lab method. It can be seen that aside from duty cycle the IBIS model closely correlates to the source HSPICE model. IBIS does not guarantee duty cycle.
Figure 22. Ensigna Lab Method Correlation
The above plots demonstrate that using Ensigna Lab methods of IBIS data collection to represent a LVDS driver within the IBIS specification is successful when correlated to the source HSPICE model of the LVDS driver. The more prominent points to note are that in contrast to the LVDS IBIS models generated with standard methods, V(OD) and V(OS) for the Ensigna Lab LVDS IBIS model in simulation correlates well to the source LVDS HSPICE model in simulation. The transient analysis of the LVDS driver IBIS model generated with Ensigna Lab methods demonstrates that the model now accurately represents the LVDS device.
The reason why the IBIS model of the LVDS driver generated with Ensigna Lab methods is successful in accurately representing the DC output voltage levels of the device can be found in the model's pullup and pulldown data for the device's inverting and non-inverting outputs. As previously described, the I/V characteristics of these outputs are interdependent and since the pullup and pulldown data for these outputs were gained using the Ensigna Lab method, the data reflects the interdependent relationship.
Additional Ensigna Lab Methods for LVDS IBIS Model Creation
The previously described Ensigna Lab methods will now form the necessary foundation for the additional methods to follow. These additional methods are necessary to accomplish the same goal: to created LVDS driver model that, when simulated in transient analysis correlates to the source LVDS HSPICE model.
As before, a dependent voltage source is implemented to keep the sum of the voltages between the outputs constant. Two termination resistors and a DC offset voltage are DC voltage source, V(OS) are added.
Figure 23. Additional methods schematics
Together, these resistors and offset voltage source will act as controlling parameters whose values can be specified such that the LVDS model can be "fit" to correlate to the source LVDS HSPICE model during transient analysis.
This fitting process can be accomplished in one step by pre-simulating the source HSPICE models in transient analysis ahead of time and using the results to specify values for the offset voltage source referred to as V(OS).
This additional Ensigna Lab method can be described simply: to gain the V(OH) and V(OL) values of the LVDS device through pre-simulation of the source LVDS HSPICE model. These values will then be used for V(OS) when conducting the I/V IBIS data simulations. The value of V(OH) will be used in place of V(OS) during the pullup simulations and the value of V(OL) will be used in place of V(OS) during the pulldown simulations. This allows the voltage levels to be specified exactly when the LVDS IBIS model is eventually used in simulation.
Figure 24. Additional methods environment for gaining Voh and Vol in pre-simulation of the source LVDS HSPICE model
The above figure shows the transient simulation conditions for the source LVDS HSPICE model that will be used to gain the values of V(OH) and V(OL). The recommended 100-ohm termination is used.
The results of those transient simulations for the typical, minimum, and maximum LVDS HSPICE models are shown below.
Figure 25. Pre-Simulation results showing Voh and Vol of the source LVDS HSPICE model
V(OH) and V(OL) can be gained this way with great exactness. These values will be show that the IBIS model correlates to these same results.
The following table shows how the values of V(OH) and V(OL) should be used in I/V IBIS data simulations.
Figure 26. Additional methods table1
The value of V(OH) is again used for V(OS) during the pullup simulations and the value of V(OL) for V(OS) during the pulldown simulations. In this way, the V(OH) and V(OL) voltage levels can be specified exactly when the LVDS IBIS model is eventually used in simulation. Also, the values of the termination resistors have been set to 1 ohm.
The results of the LVDS IBIS model compared to the LVDS HSPICE model in transient analysis << IBIS RED, HSPICE BLUE >> shows the output voltage levels of both models are identical. This is because they were able to be specified by setting the value of V(OS) to V(OL) and V(OH). There are some differences in the shape of the waveforms, but the important point is the exact correlation in DC voltage levels.
Figure 27. Additional methods correlation FIN1101 IBIS v. HSPICE
When comparing the transient simulation results of the LVDS IBIS model created without including the dependent source to the LVDS HSPICE model, there is a small discrepancy in V(OL). These transient simulation results show the usefulness of continuing to use the dependent voltage source during the additional Ensigna Lab method of gaining IBIS I/V data.
Figure 28. Importance of continuing to use the dependent voltage source with the additional Ensigna Lab methods FIN1101 IBIS v. HSPICE
The syntax for instantiating the Ensigna Lab simulation environments is shown here in HSPICE syntax. By simply commenting and uncommenting different schemes, it is possible to perform I/V and V/t IBIS simulations for both the inverting and noninverting outputs.
Figure 29. HSPICE syntax describing all Ensigna Lab methods
************************************
*** IBIS SIMULATION CONDITIONS ***
*** ***
* << DOP SIMS >>
EV1 IN0M GNDEXT POLY(1) IN0P GNDEXT 0 -1
*EV2 OUT0M GNDEXT POLY(1) OUT0P GNDEXT 2.4095 -1
* << DON SIMS >>
*EV1 IN0P GNDEXT POLY(1) IN0M GNDEXT 0 -1
*EV2 OUT0P GNDEXT POLY(1) OUT0M GNDEXT 2.4095 -1
* << PU SIMS >>
*Rfixn OUT0M MID 1
*Rfixp OUT0P MID 1
*VOS MID GNDEXT DC 1.388
* << PD SIMS >>
*Rfixn OUT0P MID 1
*Rfixp OUT0M MID 1
*VOS MID GNDEXT DC 1.0215
* << TRANSIENT SIMS >>
Rfixn OUT0P MID 37.5
Rfixp OUT0M MID 37.5
VOS MID GNDEXT DC 1.20475
Furthermore, in the same environment used for I/V IBIS data collection, it is possible to tweak the results of the LVDS IBIS model in simulation by modifying the values if the terminating resistors and V(OS).
Some basic functions have been identified in the following table. The first line shows that by increasing V(OS) during the pullup data extraction, the result will be to increase both V(OH) and V(OL) when that LVDS IBIS model is eventually simulated. The line for pullup resistors shows that by increasing their value during the pullup data extraction, the result will be to decrease both V(OH) and V(OL) when that LVDS IBIS model is eventually simulated.
Figure 30. Additional methods table2
By utilizing these basic functions, it is possible to fit the LVDS IBIS model to correlate to the source LVDS HPSICE model. In the experience of the EnSigna Lab, however, this has been unnecessary because the method of using the values of V(OH) and V(OL) for the values of V(OS) has worked every time.
Conclusion
Simulating signal integrity in the early stages of design vastly improves time to market and design costs and has become a requirement in the highly competitive world of high-speed communications and networking system design. Accurate I/O models are critical to signal integrity simulation and IBIS models have become popular due to their ease of use and availability.
However, due to the fact that original IBIS models were created for a single-ended environment, there is a need for improved methods of gaining data for differential LVDS IBIS models. Solutions have been offered and the results have been proven to be successful in Fairchild's signal integrity Ensigna Lab. Implementation of the Ensigna Lab methods described here have produced accurate and correlated LVDS IBIS models as demonstrated in HSPICE simulation.
Author's Bio:
Adam Tambone is a Modeling Engineer in Fairchild Semiconductor's Ensigna Lab and Interface Design groups. He graduated in 2001 with a BSEE degree from the University of Southern Maine.
