IBIS Folks:
After some consideration and consulting with others, I am changing
the [Add Model] syntax. The information of the Add_model_mode subparameter
is moved the [Add Model] keyword as a second column parameter, and the
Add_model_mode subparameter is removed.
This was originally suggested. So rather than just having [Add Model]
reference only one model name, one or more models will be listed
under [Add Model] (one line per model) along with a second column
to provide restrictions on the mode of operation. BIRD48.3 is
issued to document this change.
This revised syntax makes [Add Model] similar to the [Driver Schedule]
syntax.
BIRD50.2 is also issued to eliminate the Add_model_mode subparameter
in the example. BIRD49.2 remains unchanged.
Bob Ross
Interconnectix/Mentor Graphics
******************************************************************************
******************************************************************************
BIRD ID#: 48.3
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, 5/29/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.
BIRD48.3 deletes some of the prior additions. The BIRD48.3
changes are noted by |**** lines, and some BIRD48.2 additions
are removed.
|=============================================================================
| 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
| 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
|
| 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: The [Add Model] keyword is invoked from a top-level model
|**** and adds the functionality that is contained in the model |**** or list of models in each line that follows. The first
|**** column contains the model name of the added model. The
|**** second column contains a model mode restriction under
|**** which the added model is used.
|****
|**** If the top-level model type is one of the I/O or 3-state
|**** models, the model mode restriction may be Driving or
|**** Non-Driving. For example, if the model mode restriction
|**** is Non-Driving, then the added model is used only in the
|**** high-Z state of a 3-state model.
|****
|**** If there is no model mode restriction, then the reserved
|**** word 'NA' is required. It is an error if the model mode
|**** restriction conflicts with the top-level model type.
|**** For example, it is an error if the top-level model type
|**** is an Open or Output type, and the mode restriction is
|**** Non-Driving. It is also an error if the top-level model
|**** type is Input, and the mode restriction is Driving.
|****
|**** The [Add Model] keyword is not defined for Terminator,
|**** Series, or Series_switch model types.
|****
|**** The model type of the added model named under the [Add
|**** Model] keyword 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]
| Model_name Mode_restriction
Bus_Hold_1 Non-Driving | Adds the electrical characteristics of
| [Model] Bus_Hold_1 the existing [Model]
| for receiver or 3-state mode only
Dynamic_clamp_1 NA | Adds the Dynmanic_clamp_1 model for
| all modes of operation
|
|==============================================================================
Add a new section (Note, this is rewritten in BIRD48.2, so no |*** lines are
shown):
BIRD48.3 removes Add_model_mode subparameter discussion.
|=============================================================================
|=============================================================================
|
| 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] keyword is
|**** positioned
| after the initial set of required and optional subparameters of the [Model]
| keyword and among the keywords under [Model].
|
|**** The [Add Model] keyword provide the name or list of names of the added
|**** models and also the mode restriction (Driving, Non-Driving or NA) under
|**** which each added model is used.
|
| ADDED MODEL:
|
| An added model is also defined using the [Model] keyword. However, special
|**** rules are discussed, and some additional keywords 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.
|
| 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.
After some reconsideration, BIRD48.3 removes the Add_model_mode subparameter
introduced in BIRD48.1. The syntax of [Add Model] is changed to a
syntax similar to [Driver Schedule] where a list of models are given under
the [Add Model] keyword. The second column is used to list the more
restrictive mode of operation for I/O and 3-state models where each added
model is used either for Driving or Non-Driving. Putting this list of
model names and associated modes of operation in the top-level model makes
it much clear what is added and under what model of operation. Consistent
with other keyword operation, the second column is required. If no mode
restriction is applicable, then the reserved word 'NA' is required.
Furthermore, it is an error if the mode restriction conflicts with the
top-level mode. So, Driving is not permitted for an Input* model, and
Non-Driving is not permitted for any of the Output* or Open* models.
******************************************************************************
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 29 10:53:08 1998
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:30 PDT