Minutes Fall '93 IBIS Open Forum Summit Santa Clara, CA, 11/12/93 Will Hobbs Attendees: Cadence Design Systems Zaki Rakib, Kumar Contec Microelectronics Maah Sango Intel Corporation Charles Anyimi, Gregg Fortner, Will Hobbs, Arpad Muranyi, Stephen Peters Interconnectix Incorporated Bob Ross Intergraph Electronics Walter Katz Logic Modeling Corporation Randolph Harr MicroSim Corporation Arthur Wong Performance Signal Integrity Vivek Raghavan Quad Design Jon Powell Quantic Laboratories Mike Ventham Siemens Nixdorf/Cadlab Ralf Bruening Texas Instruments Bob Ward Zeelan Technology Hiro Moriyasu Agenda AM All Assemble, get acquainted, have coffee Will Hobbs Intel IC vendor view of IBIS Randy Harr LMC Die 0.9 bare die spec work with National Bob Ross Interconnectix Measurement and Extraction of buffer data Stephen Peters Intel Obtaining Model Data from Simulation Break Jon Powell Quad-Design Slew Controlled Devices Arpad Muranyi Intel I/V/T Panel Handling Dynamic Char. of Buffers Lunch PM Kumar Cadence Simultaneous Switching Noise: A Package Library Based System Vivek Raghawan Performance Package Parameters Signal Integrity Break BIRD discussions: Jon Powell Quad Design BIRD 2 Stephen Peters Intel BIRDs 1, 3, 4 Open issues, action item review, summary Summit Goals * Synch up, share information * Share Industry/Company Updates * Discuss current areas of exploration and needs * Explore technical achievements, challenges * Successful techniques in use today * Problems or unsolved mysteries * Resolve ambiguity * Close in on IBIS 2.0 Definition * Identify ę94 goals * Extend state of the art * Support customersĘ needs * Make models widely available * Engage more IC vendors in IBIS activities We accomplished many of these goals. Specifically: * We reviewed the results of IBIS to date. * We learned ways in which various companies were generating or extracting model data, and shared our thoughts on how to improve this data gathering process. * We identified areas of fairly immediate future concern for IBIS, such as modeling switching noise, complex package interactions, feedback and controlled slew rate devices. * We brainstormed on solutions to certain technical problems. * We clarified some areas that had not been clear to everyone, such as monotonic entry of data. * We ratified two proposals for IBIS 2.0, one for specifying multiple rails, and one for relaxing voltage ranges so that ECL can be supported. * We reviewed another BIRD (specifying input thresholds) and generated requests for two more (related to packaging and supply noise), to focus on in upcoming Open Forum meetings. * We shared much information on specific modeling needs, customer expectations and demands from each company's perspective. * We re-affirmed the need to engage more IC Vendors in IBIS activities. * We renewed our friendships. Morning Session Will Hobbs: An IC Vendor's View of IBIS, Distribution of I/O models After we introduced ourselves, I outlined the agenda and set forth some of the goals I hoped could be achieved at the summit. I then summarized the accomplishments of the IBIS Open Forum to date. I described where models fit in the design flow of systems and components, outlined the three phases of model development and described how Intel distributes our models. Because Intel's strongest efforts are focused on new products, most Intel IBIS models have not been distributed except under non-disclosure. Of approximately 20 such models, only one, for the 82430 PCI chipset, has been generally released. Randy Harr of LMC: DIE 0.9 bare die spec work with National Randy Harr of Logic Modeling discussed the work LMC and National Semiconductor are undertaking with ARPA on the DIE MCM (Multi-Chip Module) specification, dealing with bare die on a substrate and interconnected to other die on the same substrate. Randy described some of the bare die work currently in progress. IBM is using up to 120 die on a ceramic substrate and other customers are doing chip on board. A new approach is called Chips First, in which cavities are created on the board with the die occupying the cavities, tied together through gold interconnects on an overlying layer. The big problem for MCM manufacturers is getting information about the die from the die manufacturers. (pad locations, models, dimensions, etc.). The problem is exacerbated by changes in die size and re-layout between steppings that they are not informed of. DIE = Device Information Exchange, which is now at revision 0.9, is the answer to this information flow problem. LMC is working with MCM foundries (IBM, Motorola, nCHIP, TI, Hughes, National Semiconductor, MMS), EDA vendors (Mentor, Harris EDA, Intergraph, Cadence, Racal Redac) and bare die vendors (National Semiconductor, Intel, Micron, IDT, Motorola, TI). The group is representing DIE and IBIS in SGML (standard Generalized mark-up language), a data interchange format for textual information that allows the viewer to choose the formatting. SGML is being heavily used for hypertext applications. Mosaic is a new application that "turns all of Internet to an SGML file," including video, text, sound, etc., from across the Internet. Any SGML document can therefore be viewed worldwide over Internet using Mosaic. To put IBIS ASCII into SGML format only requires putting the keywords in angle brackets instead of square ones, and a few other changes to mark end of file. Randy volunteered to help companies convert their syntax over to SGML format. There is DIE 0.9 information in vhdl.org in /pub/die/ Randy's foils went into details on the actual format of the DIE file, which is organized hierarchically, with some information required and other information optional. In addition to internally specified data, the specification allows external references to other files in other formats, including IBIS, BSDL, VHDL, WAVES and EDIF descriptions. DIE 0.9 adds a definition of what subset of IBIS data is required for DIE files. Randy suggests we add that subset definition to the IBIS specification itself. Randy's presentation ended with specific recommendations for "improvements" to IBIS: 1. Well defined measurement methodologies 2. Explicit process de-rating 3. Change the pull_up Vcc-reference to ground-reference 4. Add I/V/T modeling to pull_up and pull_down 5. Improve the package model so beam lead (TAB, ribbon) devices can be incorporated nicely 6. Clean up and normalize syntax, possibly change to SGML style Note 1: At Intel, we considered item 2 originally, and chose not to explicitly call that out for two reasons: different processes require different de-ratings, and vendors may not wish to make the size of their process variations public knowledge. -- Will Note 2: Item 1 is addressed in V1.1 of IBIS to the extent possible, since equipment varies from company to company. We (the Open Forum) may choose at some time to put out a measurement guide that improves on this. Item 3 has been discussed repeatedly and will not be changed due to backward compatibility issues. Items 4 and 5 were addressed at the Summit, and will be subjects of further discussion and BIRDs. Bob Ross of Interconnectix: Measurement and Extraction of Buffer Data Bob's foils focused on obtaining model data by measurement of silicon, for both CMOS and TTL technologies. The measurement process is largely a database management problem. The problem is in mapping data: you might not have all parts in all packages, so you have to figure out how to map data from a part in one package type into another package. It is also an inventory control problem, cataloging, mapping data. The data comes from data books and from measurement. Bob's remaining discussion focused on measurement. Sweep range is an issue, because some devices can be destroyed by sweeping beyond the rail. There are several defined buffer types (input, output, I/O, tri-state, open drain), which drives what information you collect. Collection of data from measurement is a decomposition problem, of trying to sort out the effects of clamps from buffers etc. The companies with whom Bob has worked (Zeelan and Interconnectix) do this decomposition with software. One problem is selecting measurement regions with abnormal behavior, such as non-monotonic behavior caused by device switching or "jumps" in the ESD protection during sweeps. Their software does some filtering of data to eliminate false abnormal behavior. They can also filter for monotonic behavior. Many databases contain >200 data points. They select a subset of the data, generally based on a fitting algorithm to make model smaller without sacrificing key data. Measuring with data book loads can often produce misleading results. For example, some devices connected to a 500 ohm load will exhibit large overshoot due to on-chip charge storage effects. One would rarely or never see this in a real system. IBIS specifies a 50 ohm load, but that's not always appropriate. The challenges in measuring data from parts include test board considerations; power supply selection, logic state selection, range selection, signal integrity problems, presence of nearby grounds, 50 ohm transmission line environment, clean signal sources, high speed data acquisition hardware, load configuration, method of automatic data acquisition and storage. "Clamp data is the most significant, most under-specified data in dealing with signal integrity problems." Stephen Peters of Intel: Obtaining Model Data from Simulation Stephen Peters described how Intel creates IBIS data from our internal Spice-like simulator called TIM/CSE. He also described how Intel engineers validate the data against silicon, and some of the problems in obtaining data. The model engineer acquires the I/O buffer schematic and process file from their respective engineers, and analyzes the schematic to see what portion of the design has to be modeled. (S)he also must understand enough of the circuit to know which nodes to tie to what state to produce a rising or falling edge, a high or low state. The derived model is used in a simulation into standard loads; the actual buffer circuitry design is simulated into those loads in the Intel simulator, and the results are compared against simulations of the IBIS models run on representative commercial simulators using the same loads. When silicon becomes available, curve tracers are used with a slow sweep to obtain actual data which is then correlated against the data derived from simulation. Corrections to the model are made if necessary. Jon Powell of Quad Design: Behavioral Models and Time-Varying Devices. Jon discussed the problem of modeling slew-rate controlled devices. He described one method used to obtain slew control, which involves paralleling multiple output devices and turning them on sequentially. Unfortunately, the behavior of such designs is difficult to measure with a DC measurement methodology: transistor switching transitions are not predictable from DC measurement. We therefore need a simple AC measurement technique. The other approach to controlling slew rate, using feedback, poses other problems. Feedback is not adequately addressed in IBIS so far. Jon showed an example using a SPICE and an IBIS model: with a 50 pF load, IBIS and SPICE match well, but for a 50 ohm load, the non-feedback (IBIS) model exhibited an extremely fast rise time, while the SPICE version showed the correct, slower, slew rate. (Overlap of turn-on and tun off was eliminated on that particular example that caused the difference.) Although DC measurement techniques fail to show the turn-on/off timings, by using terminated transmission lines in SPICE simulations you can see the turn-off and turn-on of various devices easily. Jon then looked at generating data from devices by using AC I/V curves: by driving different transmission line loads, you can generate different I/V data, but this is time consuming. Conclusion: Preferably, I/V data should be developed from SPICE models by the IC manufacturer, since all semiconductor vendors have internal circuit modeling capabilities. Arpad Muranyi of Intel: Present State of IBIS Modeling, and Extending it to Handle I/V/T. Arpad focused on ramps, and how they can be specified in a non-linear fashion. One problem is that at the point of transition from high to ramp-down, the V/I curves that are applied to the simulation are switched from the pull-up to the pull-down. This could cause a step, a discontinuity. Presently, as the ramp-down occurs, the voltage that acts as a pointer into the V/I curve data is the difference voltage between the output pin and the buffer output (the curve data). Jon said that Quad understands that there is a time involved in switching from the pull-up curve to the pull-down curve, and inserts a smoothing function to represent this switching transition. Arpad feels we need a surface plot to show how the V/I curves vary with respect to time. We would need four surface plots to fully specify a buffer: pull-up turn-on, pull-up turn-off, pull-down turn-on, pull-down turn-off. Data can be derived from SPICE fairly easily, but so far we haven't come up with an adequate way via measurement. If you measure devices driving into a constant voltage, you cancel package capacitance. If you measure into constant current, you cancel out inductance; measuring into a constant voltage cancels capacitive effects; and measuring into a constant impedance incurs effects from both capacitance and inductance. Although the point was understated, Arpad called me later to emphasize that he has had success with 3D modeling and that he would write up some details for distribution to attendees. Arpad's family of curves was generated by holding a voltage constant, then turning on and off the voltage, plotting current against time, then re-running at a different voltage. Turn-off time is much faster than turn-on. Turn-on time is determined by the gate R/C of the pre-driver. Generally, slew rates aren't controlled by keeping the pull-down on partially while you are turning on the pull-up (or vice-versa). Except in DC load conditions, the turn-off characteristics can probably be largely ignored. The challenges we must address: * How do we represent this surface data? * How many points are needed to describe the surface? * How can IBIS transport the data? (Some assumptions can reduce the amount of data points.) * How can this data be measured? (Need a fast current probe) * How do we deal with package effects? Panel discussion, chaired by Jon Powell and Arpad Muranyi: Handling Dynamic Characterization of Buffers Jon expressed dismay that some of the key drivers from the EDA industry were absent, notably Kellee Crisafulli of HyperLynx, and Integrity. For Quad, their primary interest is the device switching time (how long a transistor takes to turn on or off) and the delay between the turn on times of parallel devices. Stephen made the point that V/I curves vary depending on the DC point; Jon said that at least in Quad's case, they know how transistors turn on and turn off and they account for that. If IC Vendors wanted to provide the more complete V/I data, you could gain 2% more accuracy, but at the expense of huge amounts of simulation time. We don't want to so complicate the gathering of data that manufacturers will be scared off. We could have several levels of model so we could still keep it simple for those that don't want to gather the surface data. Data points could be minimized by creating a polynomial that describes the surface or describes the scaling factor to be applied to the V/I curves. Ground bounce simulation is the critical thing customers are after in wanting slew rate control information. Lunch Lunch time discussion abounded between individuals, and I wasn't taking notes. Afternoon Session Kumar of Cadence: Simultaneous Switching Noise, A Package Library Based System Key to modeling packaging noise is in the library: Cadence defines three levels in its hierarchical packaging model: I/O Cell Level (the circuit), Pin Level (bonding pad placement), Package Level. Cadence has added a mapping file that relates an I/O model to a particular Vcc and ground pin. This had been a part of the IBIS specification originally, but there was doubt that vendors would give out the mapping data, so it was dropped. To model Vcc, ground and signal coupling effects, the models need to supply Vcc information, mutual inductance and skew between switching times of outputs that share Vccs and grounds. Signal and ground mutual inductance can actually improve the ground bounce characteristics. In any case, if mutual inductance has an effect, it is worth modeling. The data needs to be used in the correct way. If mutual inductance is included, you need to keep signals in the right order and make sure all are modeled; otherwise, some effects will not be correctly modeled. Cadence would like to solicit our feedback on how packaging should be handled; is Cadence's hierarchical approach the way we want to do it? Vivek Raghawan of Performance Signal Integrity: Packaging. Vivek's presentation was a good follow-on to Kumar's discussion. IBIS as it currently exists, assumes there is no coupling between pins, that power and ground are at fixed potentials, and it ignores the fact that on-die Vdd is not equal to board Vdd, etc. Vivek discussed the complexity of the mutual coupling, approaching a complex matrix of n**2 couplings (n-= number of pins). The size of this matrix can be reduced by arbitrarily limiting scope of interest to 2 neighbor pins on a DIP, or on a PGA to 8 neighbors (but which 8? -- depends on routing). Simultaneous switching of outputs (SSO) induces ground bounce that can result in false triggering of receiving devices, or shift the inputs of the IC that is switching so the inputs falsely trigger. They also create timing delays at the receiving end. Adding in ground planes seriously complicates modeling the ground potential at different points on the plane (and chip) Likewise, adding multiple power and ground pins (as exist on most packages) is complicated-- you can't blindly assume they are in parallel. Another complication is that package wires go through discontinuities. Vivek proposes an addition to IBIS with an optional [Package] keyword. If present, specifies .pkg file to use. If absent, the package models (Rpin, etc.) in the .ibs file is used. A .pkg file would include a linear sub-circuit, with valid elements of R, L, C, K. We need a port naming convention. There was a discussion between Cadence, Performance, Quad, Contec and TI of the use of K (applicable to Spice) and RLGC(?) nXn matrix representation. Bob Ward of TI expressed the fear that if we use the SPICE syntax, it will send the wrong message to customers, that we really want to avoid SPICE syntax as much as possible. Otherwise, people may be tempted to think that SPICE is valid at the frequencies we are looking at, which is not the case. Jon Powell told us of an SSO problem at one of their customers where an IBIS model predicted a 0.4 nS rise time, but the actual rise time of the part was 2 nS, due to ground bounce delays. This underscores the need for package model improvements. A/R Kumar: Issue a BIRD on pin mapping. A/R Vivek: Address how to add more complex package model including pin to pin coupling. Break Birds BIRD 2. Jon Powell, Input Thresholds Jon' motivation in proposing BIRD #2 was to improve the usefulness of IBIS models for customers wishing to do timing analysis of their systems. Models are needed for signal integrity and for static timing analysis. The latter requires input threshold data, since otherwise you don't know what to measure the delay to. In general, we felt that we don't want to restrict IBIS to digital only, so Input thresholds have to be optional. If digital, we could default to 0.8 volts for Vil and to and 2.0 volts for Vih. We talked about an input-type parameter, such as "input = digital", input_analog = analog, input_load = .... The default input type would be digital and the default thresholds would be Vil = 0.8, Vih = 2.0. We felt the parser (or the simulator) should check for model input-type. If the input is digital and the IBIS model fails to include the threshold data, the parser (simulator) must issue a warning that says no threshold is specified, and therefore the defaults for Vil (0.8 V) and Vih (2.0 V) are assumed. This would allow for backward compatibility with IBIS 1.1 and would also allow other defaults to be used as appropriate. After this discussion, Jon volunteered to rewrite the BIRD and re-submit it. A/R Jon Powell: Re-write Bird 2 to 2.1, re-submit to the reflector for discussion at upcoming Open Forum telephone conferences. BIRD #3, Multiple Rails, Stephen Peters. Stephen outlined the problem that he had encountered on a multiple voltage processor: An output buffer was supplied by the 3.3V rail and the clamping diode was connected to the 5V rail. BIRD 3 addresses this problem. Kumar discussed Cadence's approach which calls out the rail at the top of the V/I column. After some discussion, we realized that Stephen's approach covered the same purpose and Stephen pointed out that his intention was to preserve as much as possible the same format already in IBIS. We briefly discussed Vcc relative versus ground relative specification, with no new conclusion. The observation was made that Gnd_clamp doesn't make sense if the low clamp isn't = gnd. We suggested High_clamp and Low_clamp, to which Jon Powell pointed out that just clamp is probably adequate, since the polarity of the clamp diode is implicit in the V/I data. We voted on BIRD #3 and passed it. It will be incorporated into IBIS Version 2.0. Bird #4, ECL Extension, Stephen Peters Stephen described BIRD #4 which supersedes BIRD #1. In essence, this BIRD relaxes the range over which data is collected, and requires the model file to explicitly say over what range data was generated. This BIRD, too, passed approval and will be incorporated into IBIS Version 2.0. Open Discussion, Open Issues All day, we had been collecting issues to address if we had time at the end. The list included devices that employ feedback, monotonicity, and parser improvements. Feedback, Will Hobbs and Bob Ward Bob Ward (Texas Instruments) and Will Hobbs (Intel) discussed devices that have feedback, with GTL as the front-runner of concern. The discussion addressed the real problem posed by feedback, whose characteristics depend on the reflected wave. We reached no conclusion other than that we needed to seriously address the problem quickly, and that it wasn't going to be easy to solve. Jon Powell requested a set of voltage waveforms at the output pin of GTL drivers into different loads. Monotonicity, General Discussion We clarified that one axis of data representation should be monotonic, such as the voltage axis on the V/I curve, but that we could not require that the other axis be monotonic, since we were modeling real components whose nature may not be monotonic. Parser Improvements We briefly touched on ways that the parser could be improved, such as having it check for data range compliance and monotonically represented tables. Another improvement would be if the parser could alert the user to bad or suspicious data (.e.g., message saying 29 A in middle of nA data is suspicious). Jon Powell mentioned that he had some specific suggestions on how to improve coding style but would wait until we engaged a software engineer to tackle the Golden Parser for IBIS 2.0. Conclusion, Final Comments We reviewed the goals of the summit, which the summit largely met. All attendees expressed the feeling that the summit was worthwhile, and some suggested we get together face to face much more frequently, such as every 2-3 months. We decided to get together at least twice annually, and when we were approaching a critical juncture on a particular issue we could also convene. The level of interest and involvement by the EDA industry remains extremely high, and there is a slowly increasing level of participation by IC vendors. We agreed that we must engage many more IC vendors in IBIS if we are to achieve the level of effectiveness and acceptance in the electronic industry that we feel IBIS should enjoy. It is clear that I/O models are increasing in importance and that our efforts serve a real need. Over the last year we have tackled many challenges and have succeeded in establishing IBIS as an industry standard. At this summit, we shared a tremendous amount of information, clarified our joint vision of where we are going, and created some challenging goals for ourselves for the coming year. I want to sincerely thank all those who made the effort to attend, present and participate in this summit, and I hope this level of participation will continue in the coming year as we meet in our phone conferences to tackle our challenges. And, I hope to see you all at the next IBIS Open Forum Summit.