Minutes
Fall '93 IBIS Open Forum Summit
Santa Clara, CA, 11/12/93
Will Hobbs
Part 2, Afternoon Session
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.
Received on Mon Nov 29 11:49:20 1993
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:28 PDT