-
- News
- Books
Featured Books
- design007 Magazine
Latest Issues
Current IssueCreating the Ideal Data Package
Why is it so difficult to create the ideal data package? Many of these simple errors can be alleviated by paying attention to detail—and knowing what issues to look out for. So, this month, our experts weigh in on the best practices for creating the ideal design data package for your design.
Designing Through the Noise
Our experts discuss the constantly evolving world of RF design, including the many tradeoffs, material considerations, and design tips and techniques that designers and design engineers need to know to succeed in this high-frequency realm.
Learning to Speak ‘Fab’
Our expert contributors clear up many of the miscommunication problems between PCB designers and their fab and assembly stakeholders. As you will see, a little extra planning early in the design cycle can go a long way toward maintaining open lines of communication with the fab and assembly folks.
- Articles
- Columns
Search Console
- Links
- Media kit
||| MENU - design007 Magazine
Top 10 Issues In IBIS Models
October 19, 2011 |Estimated reading time: 7 minutes
Does your company perform incoming inspection on IBIS files? Incoming quality can be checked in a matter of minutes for many models. Once a file has passed QA, it can be placed in a shared model library.
Familiarity with the IBIS website [1] and the IBIS 5 spec [2] can make troubleshooting models faster and easier. Two documents that can be particularly helpful are the IBIS Quality Checklist [3] and the IBIS Cookbook [4]. The IBIS Quality Checklist is helpful when checking a model, and for communicating issues back to a model maker. The Cookbook explains model making issues in more depth that is in the spec.
Another resource is the IBIS Model Review Committee. Model users can suggest to a model maker to submit an IBIS file for review. Each member tests the model in his company’s tools, and they reply to the model maker with their findings.
If an IBIS issue affects simulation accuracy, document it using the IBIS Quality Checklist and screenshots. These help the model maker with troubleshooting. When an issue involves simulation tools (such as an unsupported keyword), your application engineer is your best resource.
Here’s a quick glance of the Top 10 IBIS issues:Header and Setup
- TYP [Temperature] near 25°C
- Rref above 200 ohms
- Characters other than [ ] A-Z a-z 0-9 , - _ . space
- No [Notes] or [Source]
Model Data
- File has errors or warnings in ibischk
- Non-monotonicity in total current
- I-V tables not passing through 0A at 0V
- Clamp tables not covering -Vcc to +2Vcc
- Waveform tables ending too soon or too late
- Other unexpected data table characteristics
Headers and Setup
The first four of our Top 10 issues are related to either the way SPICE was set up to generate model data, or in the way the IBIS file was set up. While none of these four will prevent simulation, they impact simulation accuracy or portability.
#1: One issue that limits simulation accuracy is the setting for [Temperature] in SPICE. For the TYP corner, it is common practice to use ambient, while the IBIS spec calls for die temperature. To include self-heating, the recommended typical and hottest temperatures should be 25°C above ambient. If the TYP value of [Temperature] is 25°C, request an updated model. In the meantime, you might decide to use the model for early simulations, while awaiting the improved model.
#2: The choice of Rref for rising and falling waveforms can impact simulation accuracy. If Rref is above 200 ohms or below 30 ohms, the transition waveforms will be less accurate for a typical trace (transmission line) impedance of 50-125 ohms. Ideally, Rref should match your trace impedance (Z0).
#3: The third issue does not impact simulation. The use of characters other than [A-Za-z0-9 ,-_.] will either be used by your EDA tools, or the file will be rejected outright. There are a number of illegal characters that might appear in IBIS files, such as (<>!#). These can be replaced with legal characters, or even deleted, in a copy of the file. This works because text blocks serve as self-documentation, and have no influence on simulation results.
#4: The fourth issue is the use of keywords [File Rev], [Notes] and [Source]. These are intended to document the model for the PCB designer. For example, it matters (to the user at least) whether IBIS data was obtained from SPICE or measured silicon. In some IBIS files, the legal disclaimer typical of datasheets is placed in [Notes].
Model Data
The remaining six issues in the Top 10 list are related to model data. Problems with model data can, and usually will, lead to inaccuracy in simulation results. Here, HyperLynx Visual IBIS Editor [5] was used to view generate the graphical views of IBIS data tables. As a general rule, data issues should be communicated back to the model maker. The IBIS Quality Checklist can help communicate these issues, together with screen shots (such as Figure 1).
#5: The worst issue to encounter is a file that does not pass the parser (currently ibischk5.0.6). If a file fails the parser, the first step is to compare the file’s name to [File Name] and change one if they do not match. Next, one can check [Notes], where expected errors and warnings might be documented. Finally, one can examine the parser messages, and decide whether to proceed with simulation, while contacting the model maker. Please note that the latest version of the parser [6] should always be used, since ibischk performs checks based on [IBIS Ver].
#6: Perhaps the most serious data issue is non-monotonicity in total current. Non-monotonicity often occurs in an individual table, but total current should always be monotonic (within numeric noise). Normally, one would expect output to be “clamped” at both rails, and normal clamping is seen below 0V in Figure 1. On the other hand, the current above Vcc decreases unexpectedly.
#7: Another easily recognized issue is total current not passing through 0A at 0V. When current is in the upper-right or lower-left quadrant (Figure 2), power is being dissipated in the I/O buffer. But when current is in either of the other two quadrants, the I/O buffer has become a power generator! In SPICE, numeric noise often results in nanoamps of current at 0V, but larger currents are worrisome.
Figure 1. Severe non-monotonicity.
Figure 2. Excessive current (100mA) at 0V.
#8. One issue arises not from the data itself, but from the way various EDA tools use the table data. When a [Power Clamp] table covers only –Vcc to 0V (Vcc-relative), the IBIS spec does not specify how the table is extended from 0V to +2Vcc. Thus EDA tools must generate extrapolated data, but there are several methods: Use 0A, use the last point in the table (not necessarily 0A), or do a linear extrapolation. Clearly, each of these results in different values. To remove this tool sensitivity, the [Power Camp] table should cover –Vcc to +2Vcc. Often, a few points at 0A can be added to the [Power Clamp] table for 0V to +2Vcc. You can then proceed with simulation while verifying the change with the model maker.
#9. Another extrapolation issue arises when a Waveform table ends too soon, as seen in Figure 3a. In this case, the voltage at the end of a transition is not the voltage for the start of the following transition. Ideally, all rising and falling waveform tables reach steady state (flat slope) by the end of the table (Figure 3b).
Figure 3a. Non-zero slope requires extrapolation to complete transition.
Figure 3b. The flat slope means waveform table is complete.
#10. Performing a graphical check of data tables can uncover other unexpected data table characteristics. For example, in Figure 3, there are not enough points in the transition region, while Figure 4 has many points. Because IBIS generally uses a point-to-point linear fit for curves, large changes in slope between line segments can lead to inaccuracy in simulation results. Fortunately, this has become less common as model makers have transitioned to s2ibis3 [7].
Other unusual data table characteristics are shown in Figures 4 and 5. Figure 4 shows a waveform table with ringing, something that is impossible with a purely resistive load. In this case, the model maker included the chip package as part of the simulation. In Figure 5, the model maker understood that current must be 0A at 0V; this was achieved by “fixing” that table point, resulting in a large and unexpected change in slope.
Figure 4. Unexpected ringing in falling waveform.
Figure 5. Unexpected change in slope in clamp table.
Into the Future
IBIS model quality is improving, as more people use the Quality Checklist [3] and cookbook [4], and request reviews from the IBIS Model Review Committee. The IBIS Quality and Cookbook task groups are working on materials for other model types, such as Touchstone/S-parameters and IBIS-AMI.
The goal of IBIS remains the same – portable models that work across applications, across EDA tools, and across operating systems. This goal benefits chip designers, allowing them to offer the same model to all users. This ultimately benefits you, the PCB designer, with quality models ready for designer simulations.
References
1. IBIS Home Page www.eda.org/ibis/2. IBIS 5 Specification http://eda.org/pub/ibis/ver5.0/3. IBIS Quality Checklist www.eda.org/pub/ibis/quality_wip/4. IBIS4 Cookbook www.eda.org/ibis/cookbook/cookbook-v4.pdf5. HyperLynx Visual IBIS Editor (Mentor Graphics), available for free download here.6. IBIS Parser (ibischk) www.eda.org/ibis/ibischk5/7. s2ibis3 www.iometh.com/Product/s2ibis3/index.html
Lynne Green is President of Green Streak Programs and Chair of the IBIS Model Review Committee. She has 30 years of experience in high-speed electronics, including design and analysis, model creation and validation for PCB and semiconductor designs. Lynne holds a PhD in electrical engineering, an MSEE and an MS in physics.