IBIS BIRD48.1 Add Model

From: Bob Ross <bobr@emicx.mentorg.com>
Date: Fri May 01 1998 - 17:22:52 PDT

IBIS folks:

Per the April 24, 1998 meeting and some subsequent thinking, BIRD48.1 is
issued to add a subparamater to describe model usage of the added
model that is described by the [Model] keyword. This new, optional sub-
parameter in the added model is:

  Add_model_mode

Its parameters can be

  Output or Non_Output

This would set the mode only for 3-state and I/O models. It would not
be used for Output, Input, or Terminator models since the includion
of the added model already presupposes that the added capabilty is
to be used.

If the optional sub-parameter Add_model_state is omitted, then the
called added model is to be at all times for all [Models] called by
[Add Model]. However, if the usage of the [Model] is to be restricted
to either the output mode or non-output modes for either 3-state or I/O*
models for which models are to be added, then the Add_model_mode subparameter
describes the restriction.

For example, if the model is to be used only for the high-Z or input modes
of a 3-state or I/O* model, then the "Non-Output"argument would be used.

BIRD48.1 also captures some changes in the [Model] keyword associated
with the the [Add Model] and Add_model_mode functionality these are
shown by |** lines,

The changes plus some other minor editorial corrections are noted by
|* lines.

Bob Ross
Interconnectix/Mentor Graphics

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

BIRD ID#: 48.1
ISSUE TITLE: Add Model
REQUESTER: Neven Orhanovic, Bob Ross, Mentor G., Arpad Muranyi, Intel
DATE SUBMITTED: 4/2/98, 5/1/98
DATE ACCEPTED BY IBIS OPEN FORUM: Pending

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

STATEMENT OF THE ISSUE:

A method is needed to add model feature details to an existing IBIS [Model]
for unanticipated technical expansion requirements.

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

STATEMENT OF THE RESOLVED SPECIFICATIONS:

Under the [Model] keyword, enter the addtional Add_model_mode
subparameter - changes are noted by |** lines in the [Model]
keyword description.

|=============================================================================
| Keyword: [Model]
| Required: Yes
| Description: Used to define a model, and its attributes.
| Sub-Params: Model_type, Polarity, Enable, Vinl, Vinh, C_comp, Vmeas, Cref,
| Rref, Vref, Add_model_mode
| Usage Rules: Each model type must begin with the keyword [Model]. The
| The model name must match the one that is listed under
| [Pin] or [Series Pin Mapping] keyword and must not contain
| more than 20 characters. A .ibs file must contain enough
| [Model] keywords to cover all of the model names specified
| under the [Pin] and [Series Pin Mapping] keywords, except
| for those model names that 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.
|
| Model_type must be one of the following:
|
| Input, Output, I/O, 3-state, Open_drain, I/O_open_drain,
| Open_sink, I/O_open_sink, Open_source, I/O_open_source,
|** Input_ECL, Output_ECL, I/O_ECL, Terminator, Series,
|** Series_switch, Dynamic_clamp, and Bus_hold
|
| Special usage rules apply to the following. Some definitions
| are included for clarification:
|
| Input These model types must have Vinl and Vinh
| I/O defined. If they are not defined, the
| I/O_open_drain parser issues a warning and the default
| I/O_open_sink values of Vinl = 0.8 V and Vinh = 2.0 V are
| I/O_open_source assumed.
|
| Input_ECL These model types must have Vinl and Vinh
| I/O_ECL defined. If they are not defined, the
| parser issues a warning and the default
| values of Vinl = -1.475 V and Vinh =
| -1.165 V are assumed.
|
| Terminator This model type is an input-only model
| that can have analog loading effects on the
| circuit being simulated but has no digital
| logic thresholds. Examples of Terminators
| are: capacitors, termination diodes, and
| pullup resistors.
|
| Output This model type indicates that an output
| always sources and/or sinks current and
| cannot be disabled.
|
| 3-state This model type indicates that an output
| can be disabled, i.e. put into a high
| impedance state.
|
| Open_sink These model types indicate that the output
| Open_drain has an OPEN side (do not use the [Pullup]
| keyword, or if it must be used, set I =
| 0 mA for all voltages specified) and the
| output SINKS current. Open_drain model
| type is retained for backward
| compatibility.
|
| Open_source This model type indicates that the output
| has an OPEN side (do not use the [Pulldown]
| keyword, or if it must be used, set I =
| 0 mA for all voltages specified) and the
| output SOURCES current.
|
| Input_ECL These model types specify that the model
| Output_ECL represents an ECL type logic that follows
| I/O_ECL different conventions for the [Pulldown]
| keyword.
|
| Series This model type is for series models that
| can be described by [R Series], [L Series],
| [Rl Series], [C Series], [Lc Series],
| [Rc Series], [Series Current] and [Series
| MOSFET] keywords
|
| Series_switch This model type is for series switch
| models that can described by [On], [Off],
| [R Series], [L Series], [Rl Series],
| [C Series], [Lc Series], [Rc Series],
| [Series Current] and [Series MOSFET]
| keywords
|**
|** Dynamic_clamp These model types are for added functions
|** Bus_hold that are described in models called by the
|** [Add Model] keyword and described in a later
|** section
|
| The Model_type and C_comp subparameters are required. The
| Polarity, Enable, Vinl, Vinh, Vmeas, Cref, Rref, and Vref
| subparameters are optional. C_comp defines the silicon die
| capacitance. This value should not include the capacitance of
| the package. C_comp is allowed to use "NA" for the min and
| max values only. The Polarity subparameter can be defined as
| either Non-Inverting or Inverting, and the Enable subparameter
| can be defined as either Active-High or Active-Low.
|
| The Cref and Rref subparameters correspond to the test load
| that the semiconductor vendor uses when specifying the
| propagation delay and/or output switching time of the model.
| The Vmeas subparameter is the reference voltage level that the
| semiconductor vendor uses for the model. Include Cref, Rref,
| and Vmeas information to facilitate board-level timing
| simulation. The assumed connections for Cref, Rref, and Vref
| are shown in the following diagram:
|
| _________
| | |
| | |\ | Rref
| |Driver| \|------o----/\/\/\----o Vref
| | | /| |
| | |/ | === Cref
| |_________| |
| |
| GND
|
|** The Add_model_mode is used in models called by the [Add Model]
|** keyword to describe whether the added functionality is
|** retricted to only the "Output" or "Non-Output" modes of
|** 3-state or I/O models. This is described in a later section.
|**
| Other Notes: A complete [Model] description normally contains the following
| keywords: [Voltage Range], [Pullup], [Pulldown], [GND Clamp],
| [POWER Clamp], and [Ramp]. A Terminator model uses one or
| more of the [Rgnd], [Rpower], [Rac], and [Cac]. However, some
| models may have only a subset of these keywords. For example,
| an input structure normally only needs the [Voltage Range],
| [GND Clamp], and possibly the [POWER Clamp] keywords. If one
| or more of [Rgnd], [Rpower], [Rac], and [Cac] keywords are
| used, then the Model_type must be Terminator.
|-----------------------------------------------------------------------------
| Signals CLK1, CLK2,... | Optional signal list, if desired
[Model] Clockbuffer
Model_type I/O
Polarity Non-Inverting
Enable Active-High

|** The next line is added:
Add_model_mode Output | Optional for "added models"

Vinl = 0.8V | input logic "low" DC voltage, if any
Vinh = 2.0V | input logic "high" DC voltage, if any
Vmeas = 1.5V | Reference voltage for timing measurements
Cref = 50pF | Timing specification test load capacitance value
Rref = 500 | Timing specification test load resistance value
Vref = 0 | Timing specification test load voltage
| variable typ min max
C_comp 12.0pF 10.0pF 15.0pF
|
|=============================================================================

Following the [Model Spec] keyword will be this new keyword:

|==============================================================================
| Keywords: [Add Model]
| Required: No
| Description: References a special model to be added to an existing
| model.
| Sub-Params: None
| Usage Rules: Each [Add Model] adds to an existing model from which
| [Add Model] is invoked some additional model information
| that is documented within another [Model] of the model
| listed below:
|
| Dynamic_clamp
| Bus_hold
|
| For example, the bus hold electrical characteristics
| modeled by a restrictive Bus_hold model may added to an
| Input or I/O model.
|
| More Model_types may be added in the future to deal with
| technological advances.
|
| Refer to the Add Model Section in this document for a
| for the rules and descriptions of models that can be
| added.
|
|------------------------------------------------------------------------------
[Add Model] Bus_Hold_1 | Adds the electrical characteristics of
                                    | [Model] Bus_Hold_1 the existing [Model]
|
|==============================================================================

Add a new section:

|=============================================================================
|=============================================================================
|
| Section 6a
|
| A D D M O D E L D E S C R I P T I O N
|
|=============================================================================
|=============================================================================
|
| The [Add Model] keyword is an optional extention to an existing [Model]
| for the purposes of adding some special-purpose detail. The [Add Model]
| keyword references a new model containing this functional detail.
|
| In general, models which are used for the purposes of adding functional
| detail will still use the [Model] keyword and some subset of its associated
| keywords. The required or allowable keywords for each type of new [Model]
| that can be invoked by the [Add Model] keyword are discussed.
|
|* These subparameters which are defined under [Model] continue to be required:
|
| Model_type
| C_comp
|*
|* A new optional subparameter is needed to define when the added [Model]
|* functionality is to be used if the usage is restricted to certain modes.
|*
|* Add_model_mode Output | or Non-Output
|*
|* When Add_model_mode is omitted, or when the model that invokes the
|* the [Add Model] keyword is an Input, Terminator, Series, Series_switch, or
|* Output model, then Add_model_mode is not used - even if it is optonally
|* provided. However, when the [Add Model] keyword is used in a 3-state
|* or I/O* model, the added model works for all models of operation.
|*
|* However, if Add_model_mode is set to Output, the mode under which the model
|* is added is restricted in 3-state and I/O* models to the output mode only.
|* If the Add_model_mode is set to Non-Output, then the model under which the
|* is added is restricted to the high-Z mode in 3-state models, and to the
|* input mode in I/O* models.
|*
| [Voltage Range] is required unless all four of the reference voltages
| [Pullup Reference], [Pulldown Reference], [GND Clamp Reference], and [POWER
| Clamp Reference] are provided. These reference voltages are optional in
| as previously defined, but are all required if [Voltage Range] is not used.
|
| The Model_type subparameter will be used to determine the functional
| components that are required within that model.
|
| The [Model Spec] keyword is reserved for externally available specification
| information. It should not appear in a model reference by [Add Model].
| Instead, the [Add Model Spec] keyword is defined to provide additional
| information that is needed, but is normally not available in any data sheet.
| The model provider may possess internal, proprietary documentation that
| contains the information.
|
|=============================================================================
| Keyword: [Add Model Spec]
| Required: No
| Sub-Params: V_trig_r, V_trig_f
| Description: The [Add Model Spec] keyword defines four columns under which
| specification and information subparameters are defined for
| [Model]s which are called by the [Add Model] keyword.
|
| The [Add Model Spec] is to be used only with models for the
| Model_type: Dynamic_clamp and Bus_hold.
|
| The following subparameters are defined:
| V_trig_r Rising edge trigger voltage
| V_trig_f Falling edge trigger voltage
|
| Usage Rules: [Add Model Spec] must follow all other subparameters under the
| [Model] keyword.
|
| For each subparameter contained in the first column, the
| remaining three hold its typical, minimum and maximum values.
| The entries of typical, minimum and maximum be must be placed
| on a single line and must be separated by at least one white
| space or tab or tab character. All four columns are required
| under the [Model Spec] keyword. However, data is required
| only in the typical column. If minimum and/or maximum values
| are not available, the reserved word "NA" must be used
| indicating the typical value by default.
|
| The minimum and maximum values are used for specifications
| subparameter values that may track the min and max operation
|* conditions of the [Model]. Usually they are related to the
| Voltage Range settings.
|
| Unless noted below, each subparameter does not require having
| any other subparameter.
|
| V_trigger_r, V_trigger_f rules:
|
| The voltage trigger values for the rising and falling edges
| edges provide the starting time at which an action is
| initiated.
|
|-----------------------------------------------------------------------------
[Add Model Spec]

|* Added 3 lines below:
Add_model_mode Non-Output | The model is applied during input mode only
                                 | if the functionality is for an I/O model

|
| Subparameter typ min max
|
| Dynamic Clamp
|
V_trigger_h 3.6 2.9 4.3 | Starts power pulse table
V_trigger_f 1.4 1.2 1.6 | Starts gnd pulse table
|
| Bus Hold
|
V_trigger_h 3.1 2.4 3.7 | Starts low to high
                                                    | bus hold transition
V_trigger_f 1.8 1.6 2.0 | Starts high to low
                                                    | bus hold transition
|
|
|=============================================================================

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

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION:

After considering the Dynamic Clamp and then seeing the need for a more
general mechanism for also adding "latching" in the model - to be added
to the existing Model, a new keyword is proposed for adding special purpose
models.

New Model_types will be defined for the special purposes. The [Model Spec]
keyword will be used to add additional control or information subparameters.

Additional keywords may be proposed that apply only to the specific model
type. However, this model call method also allows using the existing
keywords to construct the added functionality.

One motivation for this alternative construction is based on BIRD45.1 for
Dynamic Clamps. BIRD45.1defines some new clamping tables. However, with a
special purpose model defined in BIRD49, the existing [GND Clamp] and [POWER
Clamp] keywords can be used along with others to add a clamp that has a
controlled reference shift over time.

A similar motivation is BIRD50 for a new Bus_hold mechanism. The terminology
is still up for discussion. This mechanism can be used to add to the
Input or I/O model a Bus-Hold Circuit similar to how they are being currently
implemented - via a weak output stage that switches according to thresholds.
This mechanism also models the functionally of some proprietary structures
that also produce a latching effect via some weak output stages.

An alternative that was intially considered was to lump several "related"
extensions into its own Model_type (the Model_types could even be called
Extension_1, Extension_2, etc.) However after considering this for the
Dynamic Clamp and Bus Hold functionality, this was rejected. The interaction
of several Model_type specific rules would be combersome and confusing to
document.

BIRD48 also defines a consistent and understandable mechanism [Add Model]
to add electrical and informational functionality of new feature that have
not been defined.

Using just [Model Spec] for some additional specification subparameters was
considered. However, the [Model Spec] keyword should really be used for
real, external specification subparameters. So the internal [Add Model Spec]
as added in a parallel manner to deal with internally specified parameters
that are needed for the additional model, but may not appear in data sheets
or data books.

BIRD48.1 adds the Add_model_mode subparameter to the [Model] that is being
added. Its arguments are Output and Non_Output. "Non-Output" is used
rather than "Input" because this could also be used for the high-Z mode
of a 3-state model.

BIRD48.1 also expands the [Model] keyword to capture the addtional Model_type
subparameters - Dynamic-clamp and Bus-hold. Also, the subparameter
Add_model_mode is added to the [Model] keyword description.

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

ANY OTHER BACKGROUND INFORMATION:

BIRD48 is an evolution in thinking starting with BIRD45 for dynamic clamps.
The need to consider some output models withing the clamping structure, but
the proposals were becoming extremely complex with many new keywords, and
with possible augmentation to the already complex [Driver Schedule] keyword.

Several meetings were held on this subject. The last meeting on March 11,
1998 with Chris Reid, Bob Ross, and Arpad Muranyi was held to consider these
complicated additions. The outcome was essentially a proposal that new
Model_types can be defined for specific additions, the models themselves
would could contain very well-defined information including new keywords
that were allowed only with [Model]s of that type, and that the models
would be called by an [Add Model] mechanism within another model. This seemed
to fit implementation architectures where the new model information is well
modularized (and in some cases just uses the same structures), and provided
electrical information that is additive (or subtractive) to the existing
models.

The proposal here is an extension of what was discussed at the March 11, 1998
meeting based on some further reflections to associate any new functionality
with its own Model_type.

******************************************************************************
Received on Fri May 1 17:26:34 1998

This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:29 PDT