Subject: IBIS BIRD48.2 Add Model

From: [email-masked] (Bob Ross)
Date: Thu, 21 May 98 15:42:03 PDT

IBIS folks:

You will be receiving BIRD48.2 (this mail), BIRD49.2, and BIRD50.1.  They
are related to added model functionality changes.  We are considering them
for resolution at the next IBIS meeting on June 5, 1998.

BIRD48.2 contains some changes discussed at the May 15, 1998 IBIS meeting
plus responses to some other suggestions made offline and a few text
corrections.

Under the [Model] keyword, the Model_type set of subparameters now 
includes Dynamic_clamp and Bus_hold. 

The Add_model_mode subparameters are changed from Output and Non-Output
to Driving and Non-Driving.

Moving Add_model_mode to the top-level model was discussed.  The advantage
is that it would be associated directly with the I/O* or 3-state
subparameters.  However, since the top-level model can call several added
models, and these added models can be used for different modes of operation,
one Add_model_mode subparameter at the top-level is not sufficient.  The 
model mode could be a subparameter of the [Add Model] keyword.  However, 
the alternative already presented of keeping the Add_model_mode subparameter
in the added model was retained.

The V_trig_* is changed to V_trigger_*.

Corrections are noted by |*** lines.  

Also a substantial part of the Add Model Description is rewritten and
not documented by |*** lines.

Bob Ross
Interconnectix/Mentor Graphics

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

BIRD ID#:      48.2
ISSUE TITLE:   Add Model
REQUESTER:     Neven Orhanovic, Bob Ross, Mentor G., Arpad Muranyi, Intel
DATE SUBMITTED: 4/2/98, 5/1/98, 5/21/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.  BIRD48.2 changes are noted by |*** lines.

|=============================================================================
|     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 the
|**                                Add Model 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 "Driving" or "Non-Driving" modes of 
|***             3-state or I/O models.  This is described in the Add Model
|***             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
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.
|***  Usage Rules:  Each [Add Model] adds additional functionality contained
|***                in the called model to the top-level model from which 
|***                [Add Model] is invoked.  The model types for the added
|***                model must be one of the following:
|
|                      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 top-level 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 (Note, this is rewritten in BIRD48.2, so no |*** lines are
shown):

|=============================================================================
|=============================================================================
|
|                                 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 may be used under a top-level [Model] keyword to
| to add special-purpose functionality.  This section describes the structure
| of the top-level model and the added model.
|
| TOP-LEVEL MODEL:
|
| When special-purpose functional detail is needed, the top-level model
| can call one or more added models.  The [Add Model] keywords are positioned
| after the initial set of required and optional subparameters of the [Model] 
| keyword and among the keywords under [Model].
| 
| Each [Add Model] keyword gives the name of the added model.
|
| ADDED MODEL:
|
| An added model is also defined using the [Model] keyword.  However, special
| rules are discussed, and some additional keywords and subparameters that
| are used for added models introduced in this section.
|
| For added models, the required subparameters under the [Model] keyword
| are the same as for the top-level [Model] keyword:
|
|    Model_type
|    C_comp
|
| However, the only Model_type entries that are allowed are Dynamic_clamp
| and Bus_hold.
|
| An optional subparameter is used, if needed, to restrict the added model 
| operation to certain models of operation:
|
|    Add_model_mode
|
| The Add_model_mode entries are Driving and Non-Driving.  These entries 
| specify under which mode of operation the added model will used.  The
| Add_model_mode subpararameter is applicable when the top-level model is of 
| the 3-state and I/O_* model type.  For example, if the Add_model_mode
| entry is Non-Driving, then the added model is used only in the high-Z state
| of a top-level 3-state model.
|
| If the Add_model_mode subparameter is omitted, then the called added
| model is used for all top-level model modes of operation.  However, if
| the top-level model has only one mode of operation (such as with an Input
| model), then the added model that is called will be used regardless of any
| Add_mode_mode setting.
|
| The [Voltage Range] keyword is required unless all four of the reference 
| voltage keywords ([Pullup Reference], [Pulldown Reference], [GND Clamp 
| Reference], and [POWER Clamp Reference]) are provided.  Otherwise, the 
| reference voltages are optional in a similar manner as under the top-level
| [Model] keyword.
|
| The [Model Spec] keyword is used only in top-level models to describe
| external information.  The [Model Spec] keyword has no meaning and should
| not appear within an added model.  Instead, the [Add Model Spec] keyword
| is defined next to be used only within an added model.  Because the 
| subparameter infomation information contained in [Add Model Spec] relates
| to an internal function, it often not available in the data sheet.  The
| model provider may access to the information through internal documentation
| or simulation results.
|
|=============================================================================
|     Keyword:  [Add Model Spec]
|    Required:  No
| Description:  The [Add Model Spec] keyword defines four columns under which
|               specification and information subparameters are defined for
|***               added models.
|***  Sub-Params:  V_trigger_r, V_trigger_f
|
|*** Usage Rules: The [Add Model Spec] is to be used only with added models 
|***            designated by the model types Dynamic_clam and Bus_hold.
|                
|               The following subparameters are used:
|***              V_trigger_r           Rising edge trigger voltage
|***              V_trigger_f           Falling edge trigger voltage
|
|               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 [Add 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 to
|***            indicate the typical value by default.
|
|***            The values in the minimum and maximum columns are usually
|***            related to the values in the corresponding columns for  
|***            voltage ranges.
|
|***            Unless noted, no [Add Model Spec] subparameter requires any
|***            other subparameter.
|      
|               V_trigger_r, V_trigger_f rules:
| 
|               The voltage trigger values for the rising and falling edges
|***            provide the starting time when an action is initiated.
|               
|-----------------------------------------------------------------------------
| Dynamic Clamp Example:
|
[Add Model Spec]
|   Subparameter          typ        min        max
|
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 Example:
|
[Add Model Spec]
|   Subparameter          typ        min        max
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.

BIRD48.2 changes the subparameters of Add_model_mode to Driving and
Non-Driving to be more representative of the actual modes of operation of
top-level 3-state and I/O_* buffers.

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

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.

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