Text item: Text_1
Attached are all of the cleaned up BIRD files as of 2/2/94. (They
should end up concatenated below. These will also be posted to
vhdl.org as soon as I figure out how to get them there.) I have
cleaned up formatting inconsistencies and problems (such as converting
tabs to spaces). I have named the files with p (new/pending), a
(approved), and d (dead) prefixes (such as abird3_0.txt, for approved
BIRD 3.0).
- Derrick Duehren
Text item: bird.txt 2/2/94 10:01A
BIRD filename convention:
pbirdn_n.txt new/pending
abirdn_n.txt approved
dbirdn_n.txt dead
--------------------------------------------------------------------------------
Howdy, 9/15/93
The following is your key to getting issues resolved in the IBIS Open Forum.
It's called a "Buffer Issue Resolution Document" or "BIRD". Issues must be well
thought out and clearly documented using this template to be placed on
the agenda of a future IBIS Open Forum.
Here's how the process works. Write up your issue and submit it to Will. Will's
group will do a preliminary check for completeness and (potentially) send your
BIRD back to you. If not, Will will post the issue to the reflector. Each issue
must be out for review for two weeks before the Open Forum will vote on it.
During that time, you will be expected to answer questions related to your BIRD.
In each meeting announcement, Will will list those BIRDs that are ready for a
vote at that meeting. A BIRD will be accepted if EVERYONE at the meeting agrees
with it.
Please note that Open Forum time will not be used for detailed BIRD review, but
rather for confirming consensus. Detailed review MUST ensue during the two-week
review cycle via emails. Dissenters should not wait until the Open Forum to
express their opinions.
So far the group has been exceedingly cooperative, achieving a 1.0 spec in only
a couple of months. Hopefully this process will allow us to use time more
efficiently, while maintaining the same flavor in the larger group setting.
Regards, Don Telian
NOTE: All text in french brackets is for explanation only and should be deleted.
---------------------------- cut here -----------------------------------
Buffer Issue Resolution Document (BIRD)
BIRD ID#: {don't fill in, will be filled in by Will Hobbs for tracking}
ISSUE TITLE: {one line description of your issue}
REQUESTOR: {your name and company}
DATE SUBMITTED: {date you sent to Will}
DATE REVISED: {revision date}
DATE ACCEPTED BY IBIS OPEN FORUM: {status or date BIRD accepted}
*******************************************************************************
*******************************************************************************
STATEMENT OF THE ISSUE:
{Place a short description of your issue here. People should be able
tell by reading this if they care about this in less than 1 minute.}
*******************************************************************************
STATEMENT OF THE RESOLVED SPECIFICATIONS:
{For new keywords, write the text EXACTLY AS IT SHOULD APPEAR in a
future IBIS specification. If this is a change, state the old text
and the new text again EXACTLY AS IT SHOULD APPEAR. Be sure to give
intended location in the specification.}
*******************************************************************************
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:
{There are many "experts" reviewing this document. Your reasons, analysis,
and justifications must be precise and well documented, or your BIRD will
be sent back to you. Use this section to show that you've done your
homework, and answer all questions that will undoubtedly be asked. If
your issue is a change instead of an enhancement, document how backward
compatibility is to be addressed.}
*******************************************************************************
ANY OTHER BACKGROUND INFORMATION:
{These documents will be archived, so use this section to carry any detail
that is not essential to the previous section, but should not be lost.}
*******************************************************************************
Text item: pbird8_0.txt 2/2/94 10:17A
*******************************************************************************
*******************************************************************************
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.
********************************************************************************
Text item: pbird7_2.txt 2/2/94 10:12A
*****************************************************************************
*****************************************************************************
Buffer Issue Resolution Document (BIRD)
BIRD ID#: 7.2
ISSUE TITLE: Open Specification Completion
REQUESTOR: Bob Ross, Interconnectix, Inc.
DATE SUBMITTED: January 13, 1994
DATE REVISED: January 31, 1994, February 1, 1994
DATE ACCEPTED BY IBIS OPEN FORUM: {pending}
*****************************************************************************
*****************************************************************************
STATEMENT OF THE ISSUE:
Model_type "Open_drain" provides insufficient coverage for "open" sided
models. For completeness, additional "open" Model_types are need. Also,
necessary ECL related Model_types are added for clarity and to avoid
several tests required before processing the [Model]. Methods to produce
[Ramp] data need to be expanded for "open" devices.
******************************************************************************
STATEMENT OF THE RESOLVED SPECIFICATIONS:
Under the keyword [Model], additional Model_type selections are added:
I/O_open_drain, Open_sink, I/O_open_sink, Open_source, I/O_open_source,
Output_ECL, I/O_ECL, Input_ECL. The [Model] keyword specification in Version
1.1 is edited to show these Model_types. Changed text is separated by blank
lines. NOTES ON DATA DERIVATION METHODS is revised to clarify the [Ramp]
measurements for open models.
The [Model] keyword is revised to the following:
|==============================================================================
| Keyword: [Model]
| Required: Yes
| Description: Used to define a model, and its attributes
| Sub-Params: Model_type, Polarity, Enable, Vinl, Vinh, C_comp
| Usage Rules: Each Input, Output, I/O, 3-state, Open_drain, I/O_open_drain,
| Open_sink, I/O_open_sink, Open_source, I/O_open_source,
| Input_ECL, Output_ECL, and I/O_ECL model must
| begin with the keyword [Model]. The model_name must match
| the one that is listed under the [Pin] keyword and must not
| contain more than 20 characters. An .ibs file must contain
| enough [Model] keywords to cover all of the model_names
| specified under the [Pin] keyword, except for those
| model_names which use reserved words (POWER, GND and NC).
| Model_names with reserved words are an exception and
| they do not have to have a corresponding [Model] keyword.
| C_comp is allowed to use "NA" for the min and max values only.
| Other Notes: A complete [Model] description normally contains the following
| keywords: [Voltage range], [Pullup], [Pulldown], [GND_clamp],
| [POWER_clamp], and [Ramp]. However, some models may have only
| a subset these keywords. For example, an input structure
| normally only needs the [Voltage range], [GND_clamp], and
| possibly the [POWER_clamp] keywords.
| Model_types with "open_sink" specify that the output has
| an OPEN side (the [Pullup] keyword is not used or I = 0mA
| for all voltages specified) AND the output SINKS current.
| Model_types with "open_drain" have the identical meaning and
| are retained for backward compatibility. Model_types with
| "open_source" specify that the output has an OPEN side (the
| [Pulldown keyword is not used or I = 0mA for all voltages
| specified) AND the output SOURCES current. Model_types with
| "_ECL" specify that the model represents and ECL type logic
| which follows different conventions for the [Pulldown] keyword.
| Note that C_comp defines the silicon die capacitance. This
| value should not include the capacitance of the package.
|
|------------------------------------------------------------------------------
[Model] model_name
Model_type Input, Output, I/O, 3-state, Open_drain, I/O_open_drain,
Open_sink, I/O_open_sink, Open_source, I/O_open_source,
Input_ECL, Output_ECL, I/O_ECL | List one only
Polarity Non-Inverting, Inverting | List one only, -if any
Enable Active-High, Active-Low | List one only, -if any
| Signals RAS, CAS, A(0-64), D(0-128),... | Local list, -if desired
Vinl = 0.8V | input logic "low" DC voltage, -if any
Vinh = 2.0V | input logic "high" DC voltage, -if any
| variable typ min max
C_comp 12.0pF 10.0pF 15.0pF
|==============================================================================
Section 3) on NOTES ON DATA DERIVATION METHOD is revised as follows:
3) Ramp Rates:
The ramp rates (listed in AC characteristics below) should be derived
as follows:
1. Start with the silicon model, remove all packaging.
2. If: The Model_type is one of the following: Output, I/O, or
3-state (not open or ECL types);
Then: Attach a 50 ohm resistor to GND to derive the rising edge
ramp. Attach a 50 ohm resistor to POWER to derive the
falling edge ramp.
If: the Model_type is Output_ECL or I/O_ECL;
Then: Attach a 50 ohm resistor to the termination voltage
(Vterm = VCC - 2v). Use this load to derive both the
rising and falling edges.
If: The Model_type is either an open_sink type or open_drain type;
Then: Attach either a 50 ohm resistor or the vendor suggested
termination resistance to either POWER or the vendor suggested
termination voltage. Use this load to derive both the rising
and falling edges.
If: The Model_type is an open_source type;
Then: Attach either a 50 ohm resistor or the vendor suggested
termination resistance to either GND or the vendor suggested
termination voltage. Use this load to derive both the rising
and falling edges.
3. and 7.: **** Delete Items 3. and 7. ****
4. - 6.: **** Renumber these Items as 3. - 5. ****
*******************************************************************************
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:
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.
For the "open" Model_types there exists several other naming methods based
on comments received and some combinations I though of. BIRD7.2 is written
in terms of (0).
(0) Retain "Open_drain" and add "I/O_open_drain" for Version 1.1 consistency.
Add "open_sink" and "open_source" Model_types. (5 new terms, 2 redundant
terms).
no pullup: | Open_sink I/O_open_sink
| Open_drain I/O_open_drain
no pulldown: | Open_source I/O_open_source
(1) Use "up" and "down". Retain Open_drain for Version 1.1 compatibility
as a redundant Model_type. (Bird7.1 - 4 new terms, 1 redundant term).
no pullup: | Open_up I/O_Open_up
| Open_drain
no pulldown: | Open_down I/O_Open_down
(2) Retain "Open_drain", but use "up" & "down" for generic names elsewhere.
(3 new terms).
no pullup: | Open_drain I/O_Open_up
no pulldown: | Open_down I/O_Open_down
(3) Use "drain", "collector", "emitter". "emitter is generic for CMOS logic &
TTL no pulldown devices. (5 new terms).
no pullup: | Open_drain I/O_Open_drain
| Open_collector I/O_Open_collector
no pulldown: | Open_emitter I/O_Open_emitter
(4) Use "drain" generically for "up", and "source" generically for "down"
for TTL and CMOS logic. (Bird7.0 - 3 new terms)
no pullup: | Open_drain I/O_Open_drain
no pulldown: | Open_source I/O_Open_source
(5) Use "Open_drain" generically to mean "Open". Test for no pullup or
no pulldown in [Model]. (1 new term)
no pullup: | Open_drain I/O_Open_drain
no pulldown: | Open_drain I/O_Open_drain
(6) Retain "Open_drain, but use "Open" generically to mean "Open". Test for
no pullup or no pulldown in [Model]. (2 new terms)
no pullup: | Open_drain I/O_Open
no pulldown: | Open I/O_Open
(7) Use "Open" generically to mean "Open". Retain "Open_drain" for Version
1.1 compatibility. Test for no pullup or no pulldown in [Model]. (2 new
terms, 1 redundant term).
no pullup: | Open I/O_Open
| Open_drain
no pulldown: | Open I/O_Open
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.
One final consideration is that whoever generates the [Model], whether through
simulation or measurement, must know beforehand the Model_type in order to
generate the [Ramp] data according to the rules. Therefore it is reasonable
to require that this information be included as part of a Version 2.0
specification. This avoids the inefficiency of forcing the simulator to
perform many tests before processing the IBIS data. The simulator can then
translate the data into its internal format and apply its own simulator-
specific compaction schemes (the simulator does not have to provide all
of the Model_types). With BIRD7.2, the IBIS Statement of Intent within
the first paragraph is preserved: "the intention of this template is to
specify a consistent format that can be parsed by software, allowing each
simulation vendor to derive models compatible with their own product."
******************************************************************************
ANY OTHER BACKGROUND INFORMATION:
Jon Powell initiated the issue in Email of October 1993 questioning whether
we needed "I/O_OPEN_DRAIN" and I/O_OPEN_COLLECTOR". He referred to the
SN74ALS641 Open Collector Tranceiver as a specific example.
Kellee Crisafulli in Email of July 1993 considered "open output devices
(open-drain, open-collector, open-source)". Furthermore, he referred to "open
collector npn" and "open collector pnp" devices. In the discussion, he proposed
new Optional (Required for open-side devices) keywords dV/dt_r_off (turn off
time of high side driver) and dv/dt_f_off (turn off time of low side driver).
Included it the discussion was the requirement that "If the pulldown table is
missing then dV/dt_r_off is required" and "If the pullup table is missing then
dV/dt_f_off is required". Kellee elaborated further on the
measurement/extraction issues of the ramp values. BIRD7.1 now addresses
the ramp specification.
The modifications on Notes on Derivations Method by Kellee Crisafulli and
Stephen Peters are added with changes for notation consistency.
The usage of "Open_up" and "Open_down" is an adaptation of one of Arpad
Muranyi's comments on BIRD7 suggesting "open pullup" and "open pulldown".
Kellee Crisafulli's last suggestion on notation has been adopted in BIRD7.2.
******************************************************************************
Text item: pbird6_1.txt 2/2/94 10:04A
*****************************************************************************
*****************************************************************************
Buffer Issue Resolution Document (BIRD)
BIRD ID#: 6.1
ISSUE TITLE: Differential Pin Specification
REQUESTOR: Bob Ross, Interconnectix, Inc.
DATE SUBMITTED: January 12, 1994
DATE REVISED: January 29, 1994
DATE ACCEPTED BY IBIS OPEN FORUM: {pending}
******************************************************************************
******************************************************************************
STATEMENT OF THE ISSUE:
Several components contain pins which operate in a differential mode with
respect to other pins. Since this operation in inherent to a component,
the IBIS document should be extended to specify this functionality.
*******************************************************************************
STATEMENT OF THE RESOLVED SPECIFICATIONS:
An additional optional keyword, [Diff_Pin], is added to the specification.
|==============================================================================
| Keyword: [Diff_Pin]
| Required: Optional
|Description: Used to associate differential pins, their peak-to-peak
| differential voltages and timing skews.
| Sub-Params: inv_pin, vdiff, tskew_typ, tskew_min, tskew_max
|Usage Rules: Entries follow these rules: Only differential pin pairs
| are entered. The [Diff_pin] column contains a non-inverting
| pin number and the inv_pin column always contains the
| corresponding inverting pin number for output and I/O output.
| The vdiff column contains the specified peak-to-peak voltage
| between pins if the pins are Input or I/O Model_types.
| For Output only differential pins, the vdiff entry is 0V.
|Other Notes: The output pin polarity specification in the table overrides
| the [Model] Polarity specification such that the pin in the
| [Diff_pin] column will be Non-Inverting and the pin in the
| inv_pin column will be Inverting. This convention allows
| one [Model] to be used for both pins.
|
| Column length limits are:
| [Diff_Pin] 5 characters max
| inv_pin 5 characters max
| vdiff 9 characters max
| tskew_typ 9 characters max
| tskew_min 9 characters max
| tskew_max 9 characters max
|
| Each line must contain either four or six columns. If "NA" is
| entered in the vdiff, tskew_typ or tskew_min columns, its
| entry will be interpreted as 0V or 0ns. If "NA" appears in
| the tskew_max column, its value will be interpreted as the
| tskew_typ value. When using six columns, the headers
| tskew_min and tskew_max must be listed.
|-------------------------------------------------------------------------------
[Diff_Pin] inv_pin vdiff tskew_typ tskew_min tskew_max
|
3 4 150mV 1ns 0ns 2ns | Input or I/O pair
7 8 0V 1ns NA NA | Output* pin pair
9 10 NA NA NA NA | Output* pin pair
16 15 200mV 1ns | Input or I/O pin pair
20 19 0V NA | Output* pin pair, tskew = 0ns
22 21 NA NA | Output*, tskew = 0ns
| * Could be Input or I/O with vdiff = 0V
*********************************************************************************
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION
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 that 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 a differential input sensitivity specification
such as "Vpp" or "VT+" and "VT-" which defines a peak-to-peak voltage between
two input pins. The vdiff column is introduced for such specification
limits (as a positive value) which would trigger an output transition. One
application is for timing analysis.
|<-- OUTPUT MEASUREMENT POINT FROM ANOTHER COMPONENT
|
|
|<-- tmax -->|
| |
|<-- tmin ->||
__________ || ____________ __
\ || / 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.
Tskew can be shown per National Interface Databook, diagram on pg 1-121:
3V _______________
/ \ INPUT TO SAME COMPONENT
1.5V__ / \
/| |\
0V ___/ | | \______________
| tPLH | |tPHL|
___________ __________ _________ __
^ ^ \ / \ / ^ D0
| Vo/2 \ / \/ Vo/2
Vo v______\ /__ __|/\|_____v DIFFERENTIAL OUTPUT
|\/| / \
| |/\| /| |\
v____________/ \__________/ | | \_______ D0
| | | |
| | Tskew | | Tskew
Tskew = |tPLH - tPHL|
Conventions similar to those in [Pin] are followed with respect to required
and optional column entries and to column lengths.
********************************************************************************
ANY OTHER BACKGROUND INFORMATION:
Introducing a [Tskew] keyword similar to [Package] (used for defaults) was
suggested and could be considered as another method for dealing with skew.
An alternative polarity mechanism for differential outputs could have been
based on the Polarity sub-parameter within the [Model]. This was not done
because Polarity is optional and also because two [Model]s would be required:
one for the "Non-inverting" pin and another for the "Inverting" pin. In
BIRD6.1, vdiff is used as an absolute difference regardless of polarity for
Input specfication, so "polarity" no longer is applicable for inputs.
However, it still may be reasonable to require two Output or I/O [Model]s
for easier translation into simulator databases. In this case, the "inv_pin"
name could be changed to "2nd_pin". Also, with a Polarity sub-parameter,
the possibility exists that the [Models] are in phase with each other. This
may be useful for double strength buffer options.
*******************************************************************************
Text item: pbird2_0.txt 1/27/94 10:41P
******************************************************************************
******************************************************************************
Buffer Issue Resolution Document (BIRD)
BIRD ID#: 2.0
ISSUE TITLE: Requiring VIH VIL Thresholds for Input Devices
REQUESTOR: Jon Powell, Quad Desgin
DATE SUBMITTED: October 4, 1993
DATE ACCEPTED BY IBIS OPEN FORUM: {likely to be superceeded}
******************************************************************************
******************************************************************************
STATEMENT OF THE ISSUE:
The V1.1 IBIS specification does not require the presence of input
thresholds on input devices. This allows data-generators to omit
thresholds and still create "IBIS LEGAL" models. Input devices with
no stated digital logic input thresholds would only be usefull if the
inputs were totaly analog devices (a condition that is not in the
main-stream of IBIS targetted devices). Requiring a low and high threshold
for all input devices is therefor a reasonable requirement that adds
information without creating undo restrictions.
******************************************************************************
STATEMENT OF THE RESOLVED SPECIFICATIONS:
No new keywords are required.
The following text to be added to the Other Notes section of the
[Model] keyword description:
The sub-parameters Vinl and Vinh are required for Model_types of:
"Input" and "I/O". Omission of Vinl or Vinh for these devices will
cause a parser error. Any other device type that contains a Vinl or Vinh
parameter will cause a parser warning.
******************************************************************************
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:
There are devices that are not Input or Outputs and are not handled by
our current set of model types. For instance:
Termination Resistor Packs
Termination Diode Packs
Descrete 2 port devices
I believe that more change is needed in this particular area but that that
change is large enough that we should discuss it at our meeting as opposed
to random email messages.
******************************************************************************
ANY OTHER BACKGROUND INFORMATION:
{These documents will be archived, so use this section to carry
any detail that is not essential to the previous section, but should not be
lost.}
******************************************************************************
Text item: dbird1_0.txt 1/27/94 10:41P
*******************************************************************************
*******************************************************************************
Buffer Issue Resolution Document (BIRD)
BIRD ID#: 1.0
ISSUE TITLE: ECL Extensions
REQUESTER: Stephen Peters, Intel Corp.
DATE SUBMITTED:
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:
*******************************************************************************
Text item: abird5_2.txt 1/27/94 10:09P
*****************************************************************************
*****************************************************************************
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.
******************************************************************************
Text item: abird4_0.txt 1/27/94 10:22P
******************************************************************************
******************************************************************************
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:
******************************************************************************
Text item: abird3_0.txt 1/27/94 10:42P
*****************************************************************************
*****************************************************************************
Buffer Issue Resolution Document (BIRD)
BIRD ID#: 3.0
ISSUE TITLE: Multiple Power Supplies and References
REQUESTER: Stephen Peters, Intel Corp.
DATE SUBMITTED: November 4, 1993
DATE ACCEPTED BY IBIS OPEN FORUM: November 11, 1993
*****************************************************************************
*****************************************************************************
STATEMENT OF THE ISSUE: The IBIS specification currently does not address
devices that use more than one supply, or devices in which the pullups,
pulldowns, power_clamp or gnd_clamp diodes are referenced to voltages other
than that specified by the [Voltage range] keyword. This BIRD proposes
a general way in which both multiple power supplies can be defined and
V/I curve can be referenced to specific supplies.
****************************************************************************
STATEMENT OF THE RESOLVED SPECIFICATIONS: The specific change involves
adding four new keywords: [Pullup reference], [Pulldown reference],
[POWER_clamp reference] and [GND_clamp reference]. These keywords are
defined as shown below. The following text replaces the current text
for the [Voltage range] keyword.
|==========================================================================
| Keyword: [Voltage range]
| Required: Yes
|Description: Used to define the power supply voltage tolerance over which
| the the model is intended to operate. It also specifies the
| default voltage rail the pullup and POWER_clamp V/I data is
| referenced to.
|Usage Rules: Actual voltages (not percentages) are to be presented in the
| usual typ, min, max format. "NA" is allowed for the min and
| max values only.
|---------------------------------------------------------------------------
| variable typ min max
[Voltage range] 5.0v 4.5v 5.5v
|===========================================================================
| Keyword: [Pullup reference]
| Required: Yes, if the [Voltage range] keyword is not present.
|Description: Used to define a voltage rail other than that defined by
| the [Voltage range] keyword as the reference voltage
| for the pullup V/I data.
|Usage Rules: Actual voltages (not percentages) are to be presented in the
| usual typ, min, max format. "NA" is allowed for the min and
| max values only.
|Other Notes: This keyword, if present, also defines the voltage range over
| which the min and max dV/dt_r values are derived.
|---------------------------------------------------------------------------
| variable typ min max
[Pullup reference] 5.0V 4.5V 5.5V
|===========================================================================
| Keyword: [Pulldown reference]
| Required: Yes, if the [Voltage range] keyword is not present.
|Description: Used to define a power supply rail other than 0v as the
| reference voltage for the pulldown V/I data. If this keyword
| is not present the voltage data points in the pullup V/I table
| are referenced to 0v.
|Usage Rules: Actual voltages (not percentages) are to be presented in the
| usual typ, min, max format. "NA" is allowed for the min and
| max values only.
|Other Notes: This keyword, if present, also defines the voltage range over
| which the min and max dV/dt_f values are derived.
|---------------------------------------------------------------------------
| variable typ min max
[Pulldown reference] 0V 0V 0V
|===========================================================================
| Keyword: [POWER_clamp reference]
| Required: Yes, if the [Voltage range] keyword is not present.
|Description: Used to define a voltage rail other than that defined by
| the [Voltage range] keyword as the reference voltage
| for the POWER_clamp V/I data.
|Usage Rules: Actual voltages (not percentages) are to be presented in the
| usual typ, min, max format. "NA" is allowed for the min and
| max values only.
|Other Notes: Refer the "NOTES ON SPECIFYING POWER SUPPLIES" section below.
|---------------------------------------------------------------------------
| variable typ min max
[POWER_clamp reference] 5.0V 4.5V 5.5V
|===========================================================================
| Keyword: [GND_clamp reference]
| Required: Yes, if the [Voltage range] keyword is not present.
|Description: Used to define a power supply rail other than 0v as the
| reference voltage for the GND_clamp V/I data. If this keyword
| is not present the voltage data points in the pullup V/I table
| are referenced to 0v.
|Usage Rules: Actual voltages (not percentages) are to be presented in the
| usual typ, min, max format. "NA" is allowed for the min and
| max values only.
|Other Notes: Refer to the "NOTES ON SPECIFYING POWER SUPPLIES" section
| below.
|---------------------------------------------------------------------------
| variable typ min max
[GND_clamp reference] 0V 0V 0V
|============================================================================
| NOTES ON SPECIFYING POWER SUPPLIES
| It is the intention that standard TTL and CMOS devices be specified
| using only the [Voltage range] keyword. However, in cases where
| the output characteristics of a device depend on more than a single
| supply and ground, or a pullup, pulldown or clamp structure is referenced
| to something other than the default supplys, the additional 'reference'
| keywords are to be used.
|
| If the [Voltage range] keyword is not present then all four of the
| other keywords must be present. If the [Voltage range] keyword is
| present the other keywords are optional and may or may not be used as
| required. It is legal (although redundant) for an optional keyword to
| specify the same voltage as specified by the [Voltage range] keyword.
******************************************************************************
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: 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 RS23 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 -12.5V -11.5V | fixes pulldown ref
[GND_clamp reference] -12.0V -12.5v -11.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.
******************************************************************************
ANY OTHER BACKGROUND INFORMATION:
******************************************************************************
Received on Wed Feb 2 23:21:08 1994
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:28 PDT