BIRD58.2

All,

Here is BIRD58.2. I am sending it both ways, in the body of the
text, plus as an attachment. Keep wichever looks better (i.e.
no line wrapping, etc).

Sincerely,

Arpad Muranyi
Intel Corporation
============================================================================
==
****************************************************************************
**
****************************************************************************
**

BIRD ID#: 58.2
ISSUE TITLE: Driver Schedule keyword clarification
REQUESTER: Arpad Muranyi, Intel Corporation
DATE SUBMITTED: 3/2/99, 5/5/99, 5/10/99
DATE ACCEPTED BY IBIS OPEN FORUM: pending

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

STATEMENT OF THE ISSUE:

The [Driver Schedule] section of the latest IBIS specification (v3.2) does
not provide enough information to the model maker and EDA tool vendor on
essential details of this keyword. The specification can be interpreted in
many different ways which can lead to serious discrepancies and
consequences.

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

STATEMENT OF THE RESOLVED SPECIFICATIONS:

A paragraph from BIRD35.3, which explains most of the gray areas, seems to
have been inadvertently left out from the specification. On top of that,
the
usage rules section was fairly unclear to many readers, resulting in a lot
of questions even in the presence of the missing paragraph.

For this reason, the usage rules section was almost completely rewritten, in
addition to pasting the missing paragraph from BIRD35.3 into it.

The additional words or rewording do not change the original intent behind
the keyword. The intention in these changes was only to spell out more
clearly how the keyword should be used so that the model maker and EDA tool
vendor could be in agreement on how the model works.

The new section(s) of BIRD58.1 are marked with a "*" character at the
beginning of each line. and the new section(s) of BIRD58.2 are marked with
two asterisks "**" at the beginning of each line.

|===========================================================================
==
| Keyword: [Driver Schedule]
| Required: No
| Description: Describes the relative model switching sequence for
referenced
| models to produce a multi-staged driver.
| Usage Rules: The [Driver schedule] keyword establishes a hierarchical
order
| between models and should be placed under the [Model] which
| acts as the top-level model. The scheduled models are then
| referenced from the top-level model by the [Driver Schedule]
| keyword.
|
|* When a multi-staged buffer is modeled using the [Driver
|* Schedule] keyword, all of its stages (including the first
|* stage, or normal driver) have to be modeled as scheduled
|* models.
|*
|* If there is support for this feature in a simulator, the
|* [Driver Schedule] keyword will cause it to use the
|* [Pulldown], [Pulldown Reference], [Pullup], [Pullup
|* Reference], [Voltage Range], [Ramp], [Rising Waveform] and
|* [Falling Waveform] keywords from the scheduled models
|* instead of the top-level model, according to the timing
|* relationships described in the [Driver Schedule] keyword.
|* Consequently, the keywords in the above list will be ignored
|* in the top-level model. Also, all other keywords not shown
|* in the above list will be ignored in the scheduled model(s).
|*
|* However, both the top-level and the scheduled model(s) have
|** to be complete models, i.e. all of the required keywords
|** must be present and follow the syntactical rules.
|*
|* For backwards compatibility reasons and for simulators which
|* do not support multi-staged switching, the keywords in the
|* above list can be used in the top-level [Model] to describe
|* the overall characteristics of the buffer as if it was a
|* composite model. It is not guaranteed, however, that such a
|* top-level model will yield the same simulation results as a
|* full multi-stage model. It is recommended that a "golden
| waveform" for the device consisting of a [Rising Waveform]
| table and a [Falling Waveform] table be supplied in the
| top-level model to serve as a reference for validation.
|
|* Even though some of the keywords are ignored in the
|* scheduled model, it may still make sense in some cases to
|* supply correct data with them. One such situation would
|* arise when a [Model] is used both as a regular top-level
|* model as well as a scheduled model.
|
|
| The [Driver Schedule] table consists of five columns. The
| first column contains the model names of other models that
| exists in the .ibs file. The remaining four columns
describe
| delays: Rise_on_dly, Rise_off_dly, Fall_on_dly, and
|** Fall_off_dly. The t=0 time of each delay is the event when
|** the simulator's internal pulse initiates a rising or falling
|** transition. All specified delay values must be equal to or
|** greater than 0. There are only five valid combinations in
|** which these delay values can be defined:
|*
|* 1) Rise_on_dly with Fall_on_dly
|* 2) Rise_off_dly with Fall_off_dly
|* 3) Rise_on_dly with Rise_off_dly
|** 4) Fall_on_dly with Fall_off_dly
|* 5) All four delays defined
|* (be careful about correct sequencing)
|*
|* The four delay parameters have the meaning as described
|* below. (Note that this description applies to buffer types
|* which have both pullup and pulldown structures. For those
|* buffer types which have only a pullup or pulldown structure,
|** the description for the missing structure can be omitted.)
|*
|* Fall_on_dly is the amount of time that elapses from the
|** internal simulator pulse initiating a FALLING edge to the
|* t=0 time of the waveform or ramp that turns the IV curve of
|* the PULLDOWN device ON, and the t=0 time of the waveform or
|* ramp that turns the IV curve of the PULLUP device OFF (if
|* they were not turned ON and OFF by another event yet,
|* respectively).
|*
|* Fall_off_dly is the amount of time that elapses from the
|** internal simulator pulse initiating a FALLING edge to the
|* t=0 time of the waveform or ramp that turns the IV curve of
|* the PULLDOWN device OFF, and the t=0 time of the waveform or
|* ramp that turns the IV curve of the PULLUP device ON (if
|* they were not turned OFF and ON by another event yet,
|* respectively).
|*
|* Rise_on_dly is the amount of time that elapses from the
|** internal simulator pulse initiating a RISING edge to the
|* t=0 time of the waveform or ramp that turns the IV curve of
|* the PULLUP device ON, and the t=0 time of the waveform or
|* ramp that turns the IV curve of the PULLDOWN device OFF (if
|* they were not turned ON and OFF by another event yet,
|* respectively).
|*
|* Rise_off_dly is the amount of time that elapses from the
|** internal simulator pulse initiating a RISING edge to the
|* t=0 time of the waveform or ramp that turns the IV curve of
|* the PULLUP device OFF, and the t=0 time of the waveform or
|* ramp that turns the IV curve of the PULLDOWN device ON (if
|* they were not turned ON and OFF by another event yet,
|* respectively).
|*
|* Note that some timing combinations may only be possible if
|* the two halves of a complementary buffer are modeled
|* separately as two open_* models.
|*
|*
|** Use 'NA' when no delay value is applicable. For each
|** scheduled model the transition sequence must be complete,
|** i.e., the scheduled model must return to its initial state.
|
|** No [Driver Schedule] table may reference a model which
|** itself has within it a [Driver Schedule] keyword.
|
| Other Notes: The added models typically consist of Open_sink (Open_drain)

| or Open_source models to provide sequentially increased
drive
| strengths. The added drive may be removed within the same
| transition for a momentary boost or during the opposite
| transition.
|
| The syntax also allows for reducing the drive strength.
|
| Note that the Rise_on_dly, Rise_off_dly, Fall_on_dly,
| Fall_off_dly parameters are single value parameters, so
| typical, minimum and maximum conditions cannot be described
| with them directly. In order to account for those effects,
| one can refer to the fastest waveform table with the delay
| number and then insert an appropriate amount of horizontal
| lead in section in those waveforms which need more delay.
|
|* Notice that the C_comp parameter of a multi-stage buffer is
|* defined in the top-level model. The value of C_comp
|* therefore includes the total capacitance of the entire
|* buffer, including all of its stages. Since the rising and
|* falling waveform measurements include the effects of
|* C_comp, each of these waveforms must be generated with the
|* total C_comp present, even if the various stages of the
|* buffer are characterized individually.
|
| Note: In a future release, the [Driver Schedule] keyword may
| be replaced by a newer method of specification that is
| consistent with some other planned extensions. However, the
| [Driver Schedule] syntax will continue to be supported.
|---------------------------------------------------------------------------

--
[Driver Schedule]
| Model_name     Rise_on_dly  Rise_off_dly  Fall_on_dly  Fall_off_dly
  MODEL_OUT      0.0ns        NA            0.0ns        NA
|
|                                  Examples of added multi-staged
transitions
  M_O_SOURCE1     0.5ns        NA            0.5ns        NA
|              low (high-Z) to high        high to low (high-Z)
  M_O_SOURCE2    0.5n         1.5n          NA           NA
|               low to high to low           low (high-Z)
  M_O_DRAIN1     1.0n         NA            1.5n         NA
|              low to high (high-Z)        high (high-Z) to low
  M_O_DRAIN2     NA           NA            1.5n         2.0n
|                  high (high-Z)           high to low to high 
|
|===========================================================================
==
****************************************************************************
**
ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:
An attempt to build an IBIS 3.2 buffer model for a three-stage buffer using
the [Driver Schedule] keyword failed.  The initial testing of this model
with the tools of two EDA vendors showed only two of the three stages
working.  This happened because the first stage of the buffer was placed
into the "main" [Model] section of the IBIS model due to a personal
interpretation of the IBIS 3.2 spec.  After consulting with several people,
it became apparent that the specification does not mention some of the key
information that is necessary to build a correct IBIS model for this kind of
a buffer.
The following paragraph in BIRD35.3 contains the missing information which
is necessary for making correct IBIS models using the [Driver Schedule]
keyword.  This section seems to have been accidentally left out from the
specification, and should be pasted into the appropriate location as shown
above.
"The new keyword [Driver Schedule] provides a syntax for sequencing other
models.  This is given as a keyword under the [Model] keyword.  It overrides
any existing [Pullup], [Pulldown] and [Ramp] or [Rising Waveform] and 
[Falling Waveform] data for that model.  However, the required tables for
[Model] are still required for backwards compatibility reasons for
simulators
which do not support multi-staged switching.  This information can be used
as a composite model cross-check, although the resulting model may not
perform in the same manner as the multi-stage model."
Numerous EMAIL responses were posted after BIRD58 was issued on 3-2-99.
Arpad Muranyi had numerous telephone conversations with Bob Ross and posted
an EMAIL response on 3-30-99.  This response was an attempt to summarize the
issues and was discussed in a subsequent IBIS Open Forum teleconference
meeting.  Arpad Muranyi received an AR to issue BIRD58.1 (this document)
based on the additional feedback.
BIRD58.1 was discussed in the Open Forum teleconference on 5-7-99.  BIRD58.2
is a result of the editorial changes that were requested in that meeting.
****************************************************************************
**
ANY OTHER BACKGROUND INFORMATION:
Telephone conversation with Bob Ross on 2-26-99 confirmed that the IBIS
specification is missing the description of some of the usage rules which
were documented in BIRD35.3 and was implemented accordingly in ICX.
****************************************************************************
**