Text item: Text_1
Following are approved BIRDs 4.0 and 5.2.
- Derrick Duehren
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ abird4_0.txt +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
******************************************************************************
******************************************************************************
Buffer Issue Resolution Document (BIRD)
BIRD ID#: 4.0
ISSUE TITLE: ECL Extensions
REQUESTER: Stephen Peters, Intel Corp.
DATE SUBMITTED: November 5, 1993
DATE ACCEPTED BY IBIS OPEN FORUM: November 11, 1993
******************************************************************************
******************************************************************************
STATEMENT OF THE ISSUE: This proposal addresses the need to extend the
IBIS specification to include devices with Emitter Coupled Logic (ECL)
type output structures.
The proposed changes are two in number:
(1) Lessening the required voltage range over which an ECL output
is characterized.
(2) Explicitly specifying under what output conditions data is
gathered for inclusion in the pullup and pulldown tables.
******************************************************************************
STATEMENT OF THE RESOLVED SPECIFICATIONS:
(1) The first change is to relax (decrease) the range of voltage values
required when tabulating the V-I characteristics of an ECL output. For an
ECL device it is proposed the range be decreased to VCC (the most positive
power supply) to VCC - 2.2 volts (currently the range is from GND - POWER
to 2*POWER). Specifically, add the following to Item 2 in the "NOTES ON
DATA DERIVATION METHOD" section of the specification:
When tabulating output data for ECL type devices, the voltage points
must span the range of VCC to VCC - 2.2V. This range applies to
both the pullup and pulldown tables. Note that this range applies ONLY
when characterizing an ECL output.
(3) Secondly, it is proposed to explicitly state in the specification under
what output conditions data is gathered for the pullup and pulldown tables
and that, in both cases, the voltage data is referenced to VCC. The
proposed explanation should be placed in the 'Other Notes' section of the
text describing the [Pulldown] and [Pullup] keywords and is as follows:
When tabulating data for ECL devices, the data in the pulldown table
is measured with the output in the 'logic low' state. In other words,
the data in the table represents the V-I characteristics of the
output when the output is at the most negative of its two logic
levels. Likewise, the data in the pullup table is measured with the
output in the 'logic one' state and represents the V-I characteristics
when the output is at the most positive logic level. Note that in BOTH
these cases the data is referenced to the VCC supply voltage, using
the equation Vtable = Vcc - Voutput.
******************************************************************************
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:
(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.
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.
******************************************************************************
ANY OTHER BACKGROUND INFORMATION:
******************************************************************************
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ abird5_2.txt +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
*****************************************************************************
*****************************************************************************
Buffer Issue Resolution Document (BIRD)
BIRD ID#: 5.2
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: December 6, 1993
DATE REVISED: December 17, 1993
DATE ACCEPTED BY IBIS OPEN FORUM: January 7, 1994
******************************************************************************
******************************************************************************
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:
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.
******************************************************************************
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.
******************************************************************************
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.
Bird 5.2 has been issued in response to comments from the Forum members
over the use of the term "NA" in Bird to indicate the lack of a connection.
NA = "not available," which would have caused confusion. This version of
the Bird has been updated to use "NC" (= "no connection") instead.
Otherrwise, there are no changes from Bird 5.1.
******************************************************************************
Received on Wed Feb 2 23:48:05 1994
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:28 PDT