Subject: IBIS Open Forum Summit Minutes, Part 1

From: Will Hobbs <[email-masked]>
Date: Mon, 29 Nov 93 11:52:07 PST

I have already fax-ed these minutes to all those who
          attended the summit, as well as many who didn't.  but to
          make sure that all those who may be interested in what
          happened at the IBIS summit, I am posting them to the ibis
          reflector.  Due to limitations in our mailing program, I've
          had to split the minutes into two parts.  This is part 1.
          Part 2 will go out under separate cover (boy, what an
          anachronism that is!).

          Regards,

          Will Hobbs
          Intel Corporation

                                    Minutes
                         Fall '93 IBIS Open Forum Summit
                           Santa Clara, CA, 11/12/93
                                   Will Hobbs
                             Part 1, Morning Session

     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.