IBIS BIRD35.2 MULTI-STAGED OUTPUTS

To IBIS Committee:

Finally, after a long delay, here is BIRD35.2!

BIRD35.2 is a complete revision of BIRD35.1 to reflect the IBIS Committee's
request for a [Model] based scheduling mechanism. BIRD35.1 focused on
scheduling a sequence of new [Pullup(n)] and [Pulldown(n) tables. BIRD35.2
now schedules other [Model]s directly.

The key aspects of BIRD35.2 are:

1. Each [Model] can contain the [Driver Schedule] keyword to override
    using the [Pullup] and [Pulldown] and transition and use that data form
    the referenced models. Even though it is overrided, this information
    is still needed, as required for downward compatibility for simulators
    which do not support the multi-staged [Driver Schedule] keyword.

2. The [Model] keyword subparameters for specifications (Vinl, Vinh,
    Vmeas, Vref, Rref, Cref) and C_comp override any data contained in
    models that are referenced in the [Driver Schedule] table.

3. Only the [Power Clamp] and [Gnd Clamp] tables under [Model] are
    used.

4. The [Driver Schedule] consists of 5 columns for defining the referenced
    Model_name, its rising_on, rising_off, falling_on and falling_off
    delays. All four columns are required. A value of zero implies
    no delay. A value of NA implies that no response occurs for that
    part of the transition. This could occur, for example, if an Open_source
    model is used for an extra bit of source current for a small period
    of time for the rising transition, but has no effect for the falling
    transition.

For background:

The multi-staged switching functionality has been on the priority list for
Version 3.0 addtions. BIRD35.2 is another proposal to address this issue.

Unlike exiting IBIS keywords, the new tables cannot be measured directly
or even be produced easily by direct decomposition and simulation of Spice
elements because of too much internal interaction. The actual construction
would be by trial and validation and based on the known architectural intent.
 
Bob Ross
Interconnectix, Inc.

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

BIRD ID#: 35.2
ISSUE TITLE: Multi-staged Outputs
REQUESTER: Bob Ross, Interconnectix, Inc.
DATE SUBMITTED: 5/13/96, 6/21/96, 10/16/96
DATE ACCEPTED BY IBIS OPEN FORUM: Pending

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

STATEMENT OF THE ISSUE:

Modeling output transitions of buffers consisting of several sequentially
switched internal devices has been a long standing request. The addition
of the [Rising Waveform] and [Falling Waveform] keywords partially addresses
the issue by waveform shaping control. However, these keywords do not model
the dynamic impedance changes during transitions. The more direct solution
is to add IBIS keywords which allow modeling the internal architecture more
closely.

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

STATEMENT OF THE RESOLVED SPECIFICATIONS:

The [Driver Schedule] keyword is introduced as a keyword under the [Model]
keyword to construct a multi-staged driver from other existing driver
models.

|==============================================================================
| Keywords: [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] table consists of five columns. The
| first column is the model names of other models that exist
| in the .ibs file. The remaining four columns describe
| delays: rising_delay_on, rising_delay_off, falling_delay_on
| and falling_delay_off. 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 begining of the low-to-high
| transition. The Rise_off_dly entry may be given to end the
| low-to-high transition and intiate a high-to-low transition
| during the rising cycle. Similarily, the Fall_on_dly gives
| the begining 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.
|
| 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.
|------------------------------------------------------------------------------
|
[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
| Bus-hold stage
  M_O_DRAIN3 NA 1.0n NA 0.5n
| high (high-Z) to low low to high (high-Z)
|
|==============================================================================

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

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:

The proposal is designed to add to the existing IBIS structures and retain
as much existing meaning as possible. The new "stage" tables follow all of
the conventions of the existing non-staged tables. For that reason,
even the subparameters R_dut, L_dut, and C_dut are permitted, although
they are not relevant nor are expected to be used.

The overall structure is to connect independently controlled stages to a
common output node. The relative relationhips between waveform controls
are used to produce phased turn-on and turn-off models. The structure can
be also be used to model other internal artifacts. These may include
providing an extra boost pulse or providing bus hold modeling.

A general objection to these structures is that they do not relate to any
externally obtained extraction. The intent of these structures is to give
a format for modeling a known architecture with behavioral blocks and
to also add some detail to existing models.

BIRD35.1 introduces a [Rising Sequence] and [Falling Sequence] tables to
control the sequencing of individual stages. This is in response to Jon
Powell's comment to make the sequencing of waveforms easier to understand
and modify. So each [Rising Waveform(n)] and [Falling Waveform(n)] table
has its start time controlled by the Sequence tables.

One technical limitation is that the Sequencing is the same for typ, min,
and max columns. Any internal shifting within the typ, min, and max columns
for the stage must be taken into account within the Waveform columns for that
stage.

BIRD35.2 removes the numbered [Pullup(n)], [Pulldown(n)], [Rising Waveform(n)]
and [Falling Waveform(n)] syntax. Instead, references by Model_name is
introduced so that existing [Model] syntax can be used.

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.

Any model that is referenced may itself be a complete model. This creates
a problem if several complete models are referenced and they contain common
information such as specification data, C_comp, and clamping information.
Some of this information can be conflicting such as timing test loads and
thresholds. The simplist resolution is to rely only on the information
withing the [Model] keyword itself. Then it can be found easily. Also,
there is no confusion whether data in other models is "added". For
example, would all of the C_comp values be added?

The syntax allows for a reduction rather than an addition in driver
strength by using the "*_off_dly". This can be used to turn off the
boost with the transition to initiate an out of phase boost. Not all
simulators may support this feature. This feature could be used to
model a bus-hold output stage.

The prohibition of [Driver Schedule] table referencing other models which
contain the [Driver Schedule] keyword is added to keep all of the scheduling
within one table for clarity and to avoid the need to test for models
referencing each other.

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

ANY OTHER BACKGROUND INFORMATION:

Jon Powell provided syntax of an existing implementation. This proposal
is intended to be compatible with it.

******************************************************************************
Received on Wed Oct 16 16:49:12 1996