OPEN REVISION

Hello IBIS members:

Bob Ross sent this to me last week, I corrected the formatting changes
the mailer made to it, then Bob sent me a revision. I'm sorry I haven't
gotten to the second re-formatting and posting of this BIRD sooner, but
I've been fighting fires. Please, do not use tabs when you submit BIRDS,
do not exceed 80 characters, and please try to get it correct the first
time. This will help me a lot. That said, ladies and gentlemen, here is
BIRD 7 for your reading enjoyment. But first, an introduction by Bob
Ross.... (drum roll)....

Here is an attempt to reopen the open-side issue. This does not address
how the open devices are handled in the simulator, but rather, how they
can be specified in a manner that covers all components.

If this BIRD is approved, then new Model_type selections are introduced
for completeness. This will make the [Model] documentation clearer and
will be the favored method to specify "open" models. It will not
prevent any of the alternative methods that currently exist.

If this BIRD is not approved, then "Open_drain" stands alone and must
be supported. But for completeness and consistency, the alternative
methods that currently exist would be the favored method for all "open"
models.

Bob Ross, Interconnectix, Inc.

*****************************************************************************
*****************************************************************************
                 Buffer Issue Resolution Document (BIRD)

BIRD ID#: XXXX
ISSUE TITLE: Open Specification Completion
REQUESTOR: Bob Ross, Interconnectix, Inc.
DATE SUBMITTED: 13 January 1994
DATE REVISED:
DATE ACCEPTED BY IBIS OPEN FORUM: {will be filled in when accepted}

*****************************************************************************
*****************************************************************************
STATEMENT OF THE ISSUE:

Model_type "Open_drain" provides insufficient coverage for "open" sided
models. For completeness, additional "open" Model_types are need.

******************************************************************************
STATEMENT OF THE RESOLVED SPECIFICATIONS:
Under the keyword [Model], additional Model_type selection choices are
given They are Open_source, I/O_open_drain, and I/O_open_source. Below
is a revision of the [Model] keyword specification in Version 1.1 edited to show
these Model_types.

|==============================================================================|
| 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, Open_source, |
| I/O_open_drain, or I/O_open_source 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. |
| 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, Open_source,
I/O_open_drain, I/O_open_source | 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

*******************************************************************************
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:

Open-drain is corrected to Open_drain as a Model_type selection. "Drain"
also is used for "collector", and "source" also is used for "emitter".

Certain pins could not be represented without the additional Model_types.
Bidirectional Open_drain pins exist in the SN74AS621, SN74ALS641, and other
devices. Open_source pins exist in some line driver components which support
both a pullup and a pulldown (sink) output. Examples include
the SN75116 and SN75118. Furthermore, some ASICs support the Open_source
configuration. Thus Open_source is included.

ASICs could be configured as I/O_open_source. Therefore this is included
for completeness.

The user may choose to model the "open" side directly through control of the
[Pullup] and [Pulldown] keyword. Omission of [Pullup] is interpreted as
Open_drain or I/O_open_drain. Omission of [Pulldown] is interpreted as
Open_source or I/O_open_source.

The user may choose to model the "open" side directly through control of the
[Pullup] and [Pulldown] data. If all of the data contain I(typ) entries of 0mA
(a minimum of two entries are required), then that operation could be
interpreted as "open". Zero valued [Pullup] data corresponds to Open_drain or
I/O_open_drain. Zero valued [Pulldown] data corresponds to Open_source or
I/O_open_source.

Without the additional Model_types, the above two approaches are the only
methods to specify "open" sides (other than Open_drain). However the additional
Model_types do not prevent the above approaches to be used.

******************************************************************************
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. This BIRD does not address
the ramp specification. This can be treated as a separate issue. The
assumption to date is that sufficient information is provided by the existing
dV/dt_r and dV/dt_f specifications.

******************************************************************************
Received on Wed Jan 19 13:40:40 1994