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.
Received on Mon Nov 29 11:49:11 1993
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:28 PDT