****************************************************************************** ****************************************************************************** BIRD ID#: 35.3 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: 12/6/96 ****************************************************************************** ****************************************************************************** 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. | |* 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. |------------------------------------------------------------------------------ | [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. BIRD35.3 adds a note to recommend a "golden waveform" to serve as a reference for validation. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: Jon Powell provided syntax of an existing implementation. This proposal is intended to be compatible with it. ******************************************************************************