Subject: Re: Bird #5

From: Will Hobbs <[email-masked]>
Date: Tue, 14 Dec 93 09:39:10 PST

Fellow IBISers,

After discussion on the reflector, Eric has revised BIRD 5 and has re-submitted 
it.  I have re-numbered it BIRD 5.1 to differentiate it from the earlier 
version.  Below are his comments and the BIRD itself.

Regards,

Will Hobbs

Will,

  In hopes of getting the discussion "back on track", I'd like to
submit the following revised Bird #5 which eliminates the need for 
any additional columns in the [Pin] section and which carefully 
observes the 80 character-per-line limit.  I suggested this to the 
forum a few days ago and haven't heard much opposition...

  Perhaps there should be a new special-interest group for 80-column
issues? :-)

--Eric Bracken <[email-masked]>

*******************************************************************************
*******************************************************************************

                 Buffer Issue Resolution Document  (BIRD)

BIRD ID#:      5.1
ISSUE TITLE:   Pin Mapping for Ground Bounce Simulation
REQUESTOR:     J. Eric Bracken, Performance Signal Integrity, Inc. and 
               C. Kumar, Cadence Design Systems, Inc.

DATE SUBMITTED:                       6 December 1993 
DATE REVISED:                        14 December 1993
DATE ACCEPTED BY IBIS OPEN FORUM:     {will be filled in when accepted}

*******************************************************************************
*******************************************************************************

STATEMENT OF THE ISSUE:

  To be better able to simulate the ground bounce effect, it is
necessary to know which pins of a part are connected to a common 
ground or power bus.  This BIRD provides a simple mechanism for 
identifying these common buses.  This improves the simulation of 
ground bounce by limiting the noise effects of switching drivers 
to other drivers and receivers on the same bus.

*******************************************************************************

STATEMENT OF THE RESOLVED SPECIFICATIONS:

  An additional OPTIONAL keyword, [Pin_Mapping], is added to the
specification.  The [Pin_Mapping] keyword must occur after the [Pin] 
declaration section for the component model when it is used.

  When [Pin_Mapping] is used, each power and ground bus is given a
unique name which must not exceed 20 characters.

  Following the [Pin_Mapping] keyword is information indicating to
which power and ground buses a given driver or receiver is connected. 
As an example of the new format, say that we have two ground buses 
(named GNDBUS1 and GNDBUS2) which each bus together 3 pins:

  Pins:    11    12     13                    21    22     23
           +     +      +                     +     +      + 
           |     |      |                     |     |      | 
           |     |      |                     |     |      |
  Buses:   +-----+------+-----> to a few      +-----+------+-----> to a few
              GNDBUS1           drivers          GNDBUS2           more

and two similarly structured power buses (PWRBUS1 and PWRBUS2):

  Pins:    31    32     33                    41    42     43
           +     +      +                     +     +      + 
           |     |      |                     |     |      | 
           |     |      |                     |     |      |
  Buses:   +-----+------+-----> to a few      +-----+------+-----> to a few
              PWRBUS1           drivers          PWRBUS2           more

 The new [Pin_Mapping] specification would be as follows:

[Pin_Mapping]      gnd             pwr
1                GNDBUS1         PWRBUS1 
2                GNDBUS2         PWRBUS2 
....
...
...
11               GNDBUS1         NA
12               GNDBUS1         NA
13               GNDBUS1         NA
....
21               GNDBUS2         NA
22               GNDBUS2         NA
23               GNDBUS2         NA
....
31               NA              PWRBUS1
32               NA              PWRBUS1
33               NA              PWRBUS1
....
41               NA              PWRBUS2
42               NA              PWRBUS2
43               NA              PWRBUS2

Explanation:

  In the above example, the first column contains a pin number; each
pin number must match one of the pin numbers declared previously in
the [Pin] section of the IBIS file.  The second column, "gnd", designates 
the ground bus connection for that pin; similarly, the third column, "pwr", 
designates the power bus connection.

  For a GND pin, such as pins 11-13 and 21-23, the entry in the "gnd"
column indicates the ground bus to which it is attached.  The entry in 
the "pwr" column is NA because there is, of course, no connection to 
any power bus.  The situation for a POWER pin (e.g. pins 31-33 and 
41-43) is analogous.

  The above example also contains two ordinary signal pins (pins 1 and
2).  For these pins, the entries in the "gnd" and "pwr" columns 
designate the power and ground buses to which their buffer models are 
connected.  Thus, for pin 1 there is an instance of the associated I-V 
model which connects to PWRBUS1 and GNDBUS1.  Pin 2 creates an 
instance of an I-V model which connects to PWRBUS2 and GNDBUS2.

  If the [Pin_Mapping] keyword is present, then the bus connections for
EVERY pin listed in the [Pin] section must be given.

  If a pin has no connection, then both the "pwr" and "gnd" entries for
it may be NA.

*******************************************************************************

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:

  One of the more serious causes of noise in digital circuits is the
voltage spike created on a device's power or ground line due to the 
sudden switching of a very large current into that line.  This can 
occur when other drivers share a power or ground bus with the device 
in question.  Most modern packages incorporate many different power 
and ground pins and then internally connect them to several different 
power and ground buses.  The drivers and receivers are carefully 
assigned to certain buses to minimize the potential impact of 
switching noise on the part's operation.

  Without a knowledge of this device-to-bus assignment, it becomes
impossible to perform even a first-order simulation of the ground 
bounce effect.  One cannot know which pins will influence any given 
driver or receiver.  The proposed BIRD attempts to rectify this 
situation, while still observing an 80-character-per-line limit in 
the IBIS file.

*******************************************************************************

ANY OTHER BACKGROUND INFORMATION:

  Please note that, in order to make the simulation possible, the
modelling engineer must specify the (self-)resistance and inductance 
for each power and ground pin in the model.  The present BIRD does not 
address any inductive or resistive drops along the internal bus--these 
are assumed to be zero (the bus is treated as a perfect short between 
pins).  Under this assumption, the equivalent impedance seen by the 
drivers on the bus can be found by taking the parallel combination of 
the series R-L impedances for each of the GND or POWER pins connected 
to the bus.

*******************************************************************************