Text item: Text_1
Following is pending BIRD 8.0 and dead BIRD 1.0.
- Derrick Duehren
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ pbird8_0.txt +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
*******************************************************************************
*******************************************************************************
Buffer Issue Resolution Document (BIRD)
BIRD ID#: 8.0
ISSUE TITLE: Specification of V/I data monotonicity REQUESTOR:
Kellee Crisafulli, HyperLynx Inc.
DATE SUBMITTED: January 29, 1994
DATE REVISED:
DATE ACCEPTED BY IBIS OPEN FORUM: {pending}
*******************************************************************************
*******************************************************************************
STATEMENT OF THE ISSUE:
Statements have been made at various meetings specific to V/I data and
monotonicity. This information has not been added to the specification. It is
therefore the intent of this BIRD to add a monotonicity statement to the version
2.0 IBIS specification.
I searched all the IBIS minutes and found the following two IBIS minutes
relating to montonicity:
-------------------------------------------------------------------------------
From meeting Nov 5, 1993
We engaged in a discussion on monotonic behavior. There are two aspects -to be
dealt with.
1) How should we deal with output buffers that exhibit non-monotonic behavior
(and in what situations does this occur)?
2) Must data be entered in the IBIS file monotonically?
1)
Non-monotonic buffer behavior: Arpad asked, "Do we require monotonic behavior
in curves?" If this is a requirement, the parser must check for monotonicity.
Jon Powell said that customers want to model non-monotonic parts. Non-monotonic
behavior can result from slow feedback designed to prevent parts from melting;
thus is is more of a DC phenomenon than an AC phenomenon. Does this pose a
convergence problem for some simulators? Is a DC representation of the curve
acceptable for some devices? Due to DC current limiting, DC measurements may
imply non-monotonic behavior that would never actually occur under real
switching conditions. How do we measure in an AC manner instead of DC manner?
Behavior that is nonmonotonic due to feedback goes into the controlled slew rate
discussion, modeling the dynamic characteristics of device. For IBIS to be
useful, it must deal with negative resistance regions.
2)
Monotonic data entry: We felt that in IBIS tables, voltage values should be
monotonically rising or falling, but that current values may change. The
parser should check whether the data is good, but it shouldn't restrict the type
of data. A BIRD against the parser should be written at some point to add
checks for this in rev 2.0. No specific AR owner was identified.
------------------------------------------------------------------------------
From the 1993 Summit minutes:
There are several defined buffer types (input, output, I/O, tri-state, open
drain), which drives what information you collect. Collection of data from
measurement is a decomposition problem, of trying to sort out the effects of
clamps from buffers etc. The companies with whom Bob has worked (Zeelan and
Interconnectix) do this decomposition with software. One problem is selecting
measurement regions with abnormal behavior, such as non-monotonic behavior
caused by device switching or "jumps" in the ESD protection during sweeps.
Their software does some filtering of data to eliminate false abnormal behavior.
They can also filter for monotonic behavior.
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.
-------------------------------------------------------------------------------
*******************************************************************************
STATEMENT OF THE RESOLVED SPECIFICATIONS:
(The proposed changes start on the 20th line after 'Keywords:' and continue for
4 lines. Note: An '*' is used to denote the changed lines)
|==============================================================================
| Keywords: [Pulldown], [Pullup], [GND_clamp], [POWER_clamp]
| Required: Yes, if they exist in the device
| Description: The data points under these keywords define the V/I curves -of
| the pulldown and pullup structures of an output buffer -and the
| V/I curves of the clamping diodes connected to the GND -and the
| POWER pins, respectively.
| Usage Rules: In each of these sections the first column contains the
| voltage value, and the three remaining columns hold the
| typical, minimum, and maximum current values. The four
| entries, Voltage, I(typ), I(min), and I(max) must be placed on
| a single line and must be separated by at least one white
| space or tab character.
| All four columns are required under these keywords, however
| data is only required in the typical column. If minimum
| and/or maximum current values are not available, the reserved
| word "NA" must be used. "NA" can be used for currents in the
| typical column, but numeric values MUST be specified for the
| first and last voltage points on any V/I curve. Each V/I
| curve must have at least 2, but not more than 100, voltage
| points.
* At least one axis of the data (voltage or current) is -required
* to be monotonic. For example if the voltage is monotonic and
* increasing, each seqential voltage point must be larger than
* the previous value.
| Other Notes: It should be noted that the V/I curve of the [Pullup] and the
| [POWER_clamp] structures are 'Vcc relative', meaning that the
| voltage values are referenced to the Vcc pin. The voltages in
| the data tables are derived from the equation:
| Vtable = Vcc - Voutput
| Therefore, for a 5V component, -5 V in the table actually
| means 5 V above Vcc, which is +10 V with respect to ground;
| and 10 V means 10 V below Vcc, which is -5 V with respect to
| ground. Vcc-relative data is necessary to model a pullup
| structure properly, since the output current of a pullup
| structure depends on the voltage between the output and Vcc
| pins and not the voltage between the output and ground pins.
| Note that the [GND_clamp] V/I curve can include quiescent
| input currents, or the currents of a 3-stated output if so
| desired.
|------------------------------------------------------------------------------
*******************************************************************************
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:
I reviewed the previous discussions and recorded the results of the summit.
*******************************************************************************
ANY OTHER BACKGROUND INFORMATION:
The interest at the summit seemed to be to make the data more human readable. As
the approach proposed at the summit doesn't seem to have any particular
advantages to simulators. (Have I missed something?)
The original intention I had was to require the data be monotonic on both axes.
This would make it easy for all simulators to handle the data. If the data has
multivalue points, i.e. it is multistable, it could be difficult to assure that
all simulators can find a stable DC operating point, and that they always switch
properly. We have modified how the HyperLynx simulator handles non-monotonic
data to insure that this problem will not occur. Is this a problem for any of
the other simulators like SPICE?
On the other hand, at least one simulator company representative felt that it is
imperative to allow non-monotonic data on one axis to properly represent the
effects of some devices.
The IBIS_CHK program must also be modified to test for this condition.
********************************************************************************
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
+++ dbird1_0.txt +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
*******************************************************************************
*******************************************************************************
Buffer Issue Resolution Document (BIRD)
BIRD ID#: 1.0
ISSUE TITLE: ECL Extensions
REQUESTER: Stephen Peters, Intel Corp.
DATE SUBMITTED: not recorded
DATE ACCEPTED BY IBIS OPEN FORUM: {transmutted to BIRD 4.0}
*******************************************************************************
*******************************************************************************
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 three in number:
(1) Adding one more choice to the [Model] keyword sub-parameter
'Model_type'
(2) Lessening the required voltage range over which an ECL output
is characterized
(3) 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 add the choice of 'ECL' to the list of allowed
choices for the 'Model_type' sub-parameter used with the [Model] keyword.
This choice must be used when the device output being described has an
ECL type output structure. Specifically, change the description of the
[Model] keyword as follows:
WAS:
[Model] model_name
Model_type Input, Output, I/O, 3-state, Open_drain | List only one
.
.
.
PROPOSED:
[Model] model_name
Model_type Input, Output, I/O, 3-state, Open_drain, ECL | list only one
.
.
.
(2) The second 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) Finally, 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:
In the following discussion I am assuming the reader understands
the basic operation of an ECL logic gate and the emitter follower output
structure. I am also defining VCC to be the most positive supply, while
GND as the most negative supply. A "totem-pole" output is the standard
type output structure with the source (emitter) of a pullup transistor
connected to the drain (collector) of a pulldown transistor.
(1) The purpose in requiring the user to specify 'ECL' in the Model_type
sub-parameter is to give a simulator an explicit indication that the device
being modeled has an ECL type output structure. As far as the IBIS spec
is concerned, the fundamental difference between an ECL output and the
standard totem-pole or open-drain/collector output is that, for ECL, data
in the PULLDOWN table is referenced to VCC and changes in VCC effect the
logic low voltage output level. This means when simulating an ECL output a
simulator must construct a different model and make different assumptions
regarding the output characteristics of the device. The following
discussion explains these differences in more detail.
Currently, voltage data points in the pulldown table are referenced
to GND. This is because in a standard totem-pole type output the output
voltage in the logic low state is determined by Vds (or Vce) of the
pulldown transistor, and the source (emitter) of this transistor is tied
to ground. However, in ECL type outputs the output voltage in the logic
low state is determined by the voltage at the base of the output emitter
follower, and this voltage is with respect to VCC, not GND. As a specific
example, it does not matter whether VCC is defined as 0v or 5v, the output
voltage of an ECL gate in the low state is always going to be about 1.7v
below the VCC supply. By the same reasoning, a shift in VCC with respect
to the other supply will not change the logic low output voltage of a
totem-pole output but it will change the logic low level of an ECL type
output.
Because the simulator cannot, apriori, determine the proper output
model (totem-pole or ECL) some indication of the output type is required.
One could argue that the simulator could inspect the data in both
tables and assume that if the range was 0 to -2.5 it was dealing with an ECL
type output, however, I don't believe this is (a) reliable (can we GUARANTEE
that no other device will be specified with those voltage ranges) and (b)
the IBIS specification should place specific implementation requirements on
a simulator. Therefore, the easiest and most reliable way to explicitly
specify the output type is with the Model_type sub-parameter.
(2) 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. Note also that there are no gnd or power clamp
diodes on ECL outputs (or inputs for that matter) and so those are
'don't care' issues.
(3) The third 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:
*******************************************************************************
Received on Wed Feb 2 23:59:23 1994
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:28 PDT