BIRD52 - [Driver Schedule] Clarifications

To IBIS Group:

BIRD52 is issued to clarify some [Driver Schedule] details for IBIS
Version 3.1.

Bob Ross
Interconnectix/Mentor Graphics

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

BIRD ID#: 52
ISSUE TITLE: [Driver Schedule] Clarifications
REQUESTER: Arpad Muranyi, Intel
DATE SUBMITTED: 6/1/98
DATE ACCEPTED BY IBIS OPEN FORUM: Pending

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

STATEMENT OF THE ISSUE:

There are a few editorial items under the [Driver Schedule] keyword section of
the IBIS specification which need to be changed for clarity and correctness.

1) The current IBIS 3.0 specification does not specify where the [Driver
Schedule] keyword must be placed in an IBIS model.

2) The current IBIS 3.0 specification only allows one number for each of the
Rise_on_dly, Rise_off_dly, Fall_on_dly, Fall_off_dly parameters under the
[Driver Schedule] keyword. It is not obvious how minimum and maximum values
can be handled for these parameters.

3) The wording of the second sentence under the usage rules section is
awkward and misleading.

4) The last example, the "bus-hold stage" is redundant in the presence of
BIRD 49.

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

STATEMENT OF THE RESOLVED SPECIFICATIONS:

1) Under the [Driver Schedule] keyword, add a new paragraph to the Usage
Rules section (indicated by asterisks "*") to clarify the correct location of
the [Driver schedule] keyword.

|*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.

2) Under the "Other Notes" section of the [Driver Schedule] keyword, add a
new paragraph (indicated by asterisks "*") to explain how this can be done
using the waveform tables.

|* 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.

3) The wording of the second sentence under the usage rules section should be
changed to the wording shown in this BIRD (indicated by asterisks "*").

| 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

4) Delete the last example.

Therefore the entire [Driver Schedule] section should be as follows:
|=============================================================================
| 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.
|
| 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
| Falling_off_dly. All values are referenced to 0 seconds for
| the start of the rising transition and 0 seconds for the start
| of the falling transition. All delays must be equal to or
| greater than 0.
|
| The Rise_on_dly entry gives the beginning of the low-to-high
| transition. The Rise_off_dly entry may be given to end the
| low-to-high transition and initiate a high-to-low transition
| during the rising cycle. Similarly, the Fall_on_dly gives
| the beginning of the high-to-low transition. The Fall_off_dly
| may be given to end the high-to-low transition and initiate a
| low-to-high transition.
|
| Use 'NA' when no transition is applicable. For each model,
| the transition sequence must be complete, i.e., it must start
| and end at the same state.
|
| Only the [Pulldown] and [Pullup] tables and transition data
| [Ramp] or [Rising Waveform] and [Falling Waveform] data are
| used from each model that is referenced. The [Model] keyword
| provides the specification information, [GND Clamp] and [POWER
| Clamp], and C_comp, regardless of information contained in
| the referenced models.
|
| It is recommended that a "golden waveform" for the device
| consisting of a [Rising Waveform] table and a [Falling
| Waveform] table be supplied under the [Model] keyword to
| serve as a reference for validation.
|
| No [Driver Schedule] may reference a model which itself has
| within it a [Driver Schedule] table 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.
|-----------------------------------------------------------------------------
[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:

1) In the process of making a model with the [Driver Schedule] keyword I
began to study the IBIS 3.0 specification for details. I found out that the
location of the keyword was not specified in the specification and left room
for various interpretations. Based on conversations with Bob Ross I found out
that it was intended to be placed inside a [Model] section which acts as a top
level model in terms of the model hierarchy.

2) In the same process, I also found that the Rise_on_dly, Rise_off_dly,
Fall_on_dly, Fall_off_dly parameters are single value parameters which cannot
describe the varying amounts of delays of the typical, minimum, and maximum
conditions. Suspecting a possible oversight I discussed this matter with Bob
Ross and I found out that the members of the IBIS Open Forum did have
discussions on this subject when the [Driver Schedule] keyword was developed.
The format of these parameters were deliberately chosen to be the way they
are. The meeting minutes outline the solution described in this BIRD, but for
some reason the suggested solution did not make it into the specification.

3) During our conversations Bob Ross pointed out to me that the wording of
the second sentence of the usage rules was awkward and should be fixed since
this work is already being written.

4) Bob Ross also asked me to request the removal of the last example in this
BIRD since BIRD 49 is in progress and covers the bus-hold features much more
accurately.

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

ANY OTHER BACKGROUND INFORMATION:

None

******************************************************************************
Received on Tue Jun 2 09:46:43 1998