Subject: Summit Minutes, Part Deux

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

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.