Subject: 3 OF 3 EXTENDED IBIS

From: [email-masked] ( Bob Ross)
Date: Sun, 20 Feb 94 18:44:52 PST

Most of the above is fairly
self-explanatory.  The key here is to realize that the four 'reference'
keywords, in effect, create separate power supply rails that override
the default [Voltage range] supply.  The intention was to create a very
general and flexible way to handle multiple supply devices and ECL.
To illustrate with some examples:

  1. An RS223 line driver has a +/- 12V output swing.  One way to specify
     this device is shown below
				typ	min	max
     [Voltage range]		12.0V	11.5V	12.5V  | fixes pullup and
						       | POWER_clamp ref
     [Pulldown reference]	-12.0V	-11.5V	-12.5V | fixes pulldown ref
     [GND_clamp reference]	-12.0V  -11.5v	-12.5V | fixes GND_clamp ref
  
     Optionally, the [Voltage range] keyword could be replaced with the
     [Pullup reference] and [POWER_clamp] reference.

  2. A device uses two supplies, a 3V supply for its I/O and a 5V supply for
     it's internal logic.  The power clamp diodes are referenced to the 5V
     supply.  Their are two equally valid ways this device can be specified.

				typ	min	max
     [Voltage range]		3.3V	3.0V	3.6V  | fixes pullup reference
     [POWER_clamp reference	5.0V	4.5V	5.5V  | fixes POWER_clamp
						      | reference
			
				typ	min	max
     [Voltage range]		5.0V	4.5V	5.5V  | fixes both pullup and
						      | POWER_clamp reference
     [Pullup reference]		3.3V	3.0V	3.6V  | overrides [Voltage
						      | range] specification
						      | on the pullup

  3. When specifying a device with an ECL type output structure, the pulldown
     curves must be referenced to the most positive supply (the same one that
     the pullup curves are referenced to).  The easiest way to do this is
     define the value of the [Voltage range] as 0v.  Both the pullup AND
     pulldown V/I curves will be referenced to 0v (remember, the pulldown
     defaults to 0v). 

				typ	min	max
     [Voltage range]		0V	0V	0V	| VCC supply
     [Pulldown reference]  	0V	0V	0V	| not really
							| required, its
							| specified for 
							| completeness
     [GND_clamp reference]	-4.5V	-3.5V	-5.5V	| ESD diode

     Alternately, one could specify the VEE supply and then override the
     default values of the pullup and pulldown references
				typ	min	max
     [Voltage range]		-4.5V	-4.0V	-5.5v	| VEE supply
     [Pullup reference]		0v	0v	0V
     [Pulldown reference]	0v	0v	0v  
     [GND_clamp reference]	-4.5V	-3.5V	-5.5V	| ESD diode

     Finally, to specify ECL logic that is used with a +5V supply
     (positive ECL) one can do the following:

				typ	min	max
     [Voltage range]		5.0V	4.5V	5.5V	| VCC supply
     [Pulldown reference]	5.0V	4.5V	5.5V	| override default

     The default references are used for the pullup and GND_clamp V/I
     curves.

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

NOTES ON BIRD4

(1)   The reason the voltage range over which an ECL output is specified
should be relaxed is that, with ECL, one is dealing with much smaller 
signal swings and terminated transmission lines.

(2)   The rational for specifying such a large voltage range was to allow
for the case of a CMOS output driving an unterminated transmission line.
When an incident voltage wave hits the end of an unterminated line it
will reflect back to the source at double the amplitude. Thus, a CMOS
output that swings rail-to-rail could see a reflection of up to 2*VCC
(or -VCC in the negative direction).  However, with an ECL output, the
output swing is only ~800mv (typically -.9v to -1.7v) and furthermore,
because of the vary nature of ECL, any transmission lines will be
terminated with an Rt close to the lines Zo.  Even in the case where the
mismatch between Zo and Rt is 2:1, the maximum reflection is .270mv,
and the voltage range at the source due to reflections is -.6 to -2.0v.
Therefore, a range of VCC to VCC -2.2v is adequate to specify the output
under any reasonable conditions, and should be enough to allow simulators
to extrapolate the curves.

(3)  The second proposal is an effort to make perfectly clear to both the
user and the person creating an IBIS specification for a particular part
how ECL device are to be handled.

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

NOTES ON BIRD5.2

  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:

  Each power and ground bus is given a unique name which must not
exceed 20 characters.

  An additional OPTIONAL keyword, [Pin_Mapping], is added to the
specification.  Following this 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

  We assume that the "signal name" for pins 11-13 and 21-23 are all
"GND", and that the names for pins 31-33 and 41-43 are all "VDD".  The 
new [Pin_Mapping] specification would be as follows:

[Pin_Mapping]      gnd             pwr
1                GNDBUS1         PWRBUS1 
2                GNDBUS2         PWRBUS2 
.....
....
....
11               GNDBUS1         NC
12               GNDBUS1         NC
13               GNDBUS1         NC
.....
21               GNDBUS2         NC
22               GNDBUS2         NC
23               GNDBUS2         NC
.....
31               NC              PWRBUS1
32               NC              PWRBUS1
33               NC              PWRBUS1
.....
41               NC              PWRBUS2
42               NC              PWRBUS2
43               NC              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 NC 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 NC.

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

NOTES ON BIRD6.2

  Since only a small percentage of components contain differential pins,
[Diff_Pin] is optional.  The component itself may be required to convey the
associations between pins for differential inputs and/or outputs.  Such cases
may occur in practice when pairs of pins are connected using closely-spaced,
coupled nets or twisted-pair cabling.

  Pins which provide complimentary outputs should not be associated with
each other when the analysis is normally done using only one pin at a
time.  However, there may be cases related to other pending extensions
(package models, power association, etc.) where association of complimentary
pins may be appropriate.

  [Diff_pin] should be used for pins designed for differential operation.
Inputs of such components have differential input sensitivity specifications 
such as "Vpp" or "VT+" and "VT-" which define the differential threshold
voltages between two input pins.  The vdiff column is introduced for such 
specification limits (the magnitudes used for both polarities) which would
trigger an output change.  Two switching cycles show that the actual switching
can occur at either polarity vdiff relative to one pin (A0_bar).  If the actual
switching completes near tmax (the threshold past the cross-over), then the
first switching completes when (A0 - A0_bar) is negative and the second when
(A0 - A0_bar) is positive.  One application of vdiff is for timing analysis
bounds. 

 |<-- OUTPUT MEASUREMENT POINT FROM ANOTHER COMPONENT
 |                                               __
 |               Polarities of vdiff relative to A0 signal show both
 |<-- tmax -->|  polarities used to bound the transition region
 |            |
 |<-- tmin ->||  (output = 0)      (output = 1)
 __________  ||  ____________      _____________
           \ || /            \    /               A0
          __\||/__          __\  /__
          +  \/  -  vdiff   -  \/  +                 DIFFERENTIAL INPUT
          __ /\ __          __ /\ __
            /  \              /  \                __
 __________/    \____________/    \_____________  A0

  For timing purposes, an output is referenced to an equal voltage cross-over
of output pins.  Setting the vdiff entry to 0V is thus chosen when the pins
are for differential outputs only.  Note, the cross-over does NOT mean that
the outputs are at 0V.

  The Tskew value is the time difference between the mid-point of the two
output transitions.  It is equivalent to the time-delay of one pin relative 
to the other pin.  Although an absolute value is specified, either pin can
delayed relative to the other pin.  This specification assumes the outputs 
are reasonably identical and the rise and fall transitions are reasonably
similar.   tdelay may relate to Tskew values of unloaded outputs, but
are considered separate in IBIS as a launch delay of the non-inverting
output relative to the inverting output.  tdelay can be either polarity.

  Tskew can be shown per National Interface Databook, diagram on pg 1-121
along with tdelay:

       3V _______________
         /               \  INPUT TO SAME COMPONENT
 1.5V__ /                 \
       /|                 |\
0V ___/ |                 | \______________
        | tPLH |          |tPHL|  
 ___________        __________    _________ __
 ^     ^   |\ Tskew/          \  /     ^    D0
 |    Vo/2 | \|<>|/            \/     Vo/2
Vo     v__ | _\  /__        __|/\|_____v        DIFFERENTIAL OUTPUT
           |   \/             /  \
 |         |   /\            /|  |\
 v_________|__/  \__________/ |  | \_______ D0
           |  |               |  | 
           |  |              >|  |< Tskew    Tskew = |tPLH - tPHL|
           |  | 
          >|  |< tdelay (positive value)                

  Conventions similar to those in [Pin] are followed with respect to required
and optional column entries and to column lengths.

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

NOTES ON BIRD7.2

Open-drain is corrected to Open_drain as a Model_type selection and is kept
for backward compatibility.  I/O_open_drain is added.  The new types with
"open_sink" and "open_source" are added to generically describe an output
with either an open [Pullup] or [Pulldown] and an output that sinks or
sources current.  Without requiring an explicit test, these new Model_types
signal that the [Pullup] or [Pulldown] tables are not defined or are not to
be used if defined.  Model_types for ECL are defined to fill the functionality
table below.  

Conditions:  |                      Model_type:
             |
pullup&down: |  Output         3-state       I/O               
no pullup:   |  Open_sink                    I/O_open_sink
             |  Open_drain                   I/O_open_drain
no pulldown: |  Open_source                  I/O_Open_source
no pullup/dn:|                                                   Input
ECL up&down: |  Output_ECL                   I/O_ECL        
ECL no up/dn:|                                                   Input_ECL

Note, "ECL" is intended to be generic.  It can be used to model "PECL" logic
spanning from Vcc = 5V to GND.  Input_ECL is redundant, but may signal the
simulator to use different default Vinl and Vinh values if these OPTIONAL
(a BIRD2.1 issue) input parameters are not specified.  

Currently, the user may choose to model the "Open" side directly through
control of the [Pullup] and [Pulldown] keyword.  Omission of [Pullup] could
be interpreted as an "open_sink" device.  Omission of [Pulldown] could be
interpreted as an "open_source" device.  However, this method was never
specified in IBIS Version 1.1 as the correct method and therefore was not
the only method to specify "Open" devices.

The user may choose to model the "Open" side directly through control of the
[Pullup] and [Pulldown] data.  If all of the data contains I(typ) = 0mA 
entries (a minimum of two entries are required), then that [Model] could be
interpreted as "open".  Zero valued [Pullup] data corresponds to "open_sink"
or "open_drain" types.  Zero valued [Pulldown] data corresponds to
"open_source" types. 

Without the additional Model_types, the above two approaches plus the existance
of "Open_drain" provide a confusing and inconsistent specification and
require the simulator to perform a variety of tests before being able to 
process the data.

The "ECL" model types are added to avoid similar confusion.

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