IBIS Folks:
In response to the comments from Kellee Chrisafulli and staff and to
comments at the June 5, 1998 IBIS meeting and comments at the IBIS Summit
Meeting on June 18, 1998, BIRD48.4 is issued (along with BIRD49.3 and
BIRD50.3).
The changes are substantial and sections have been rewritten. Some
changes are:
- The Title is changed from Add Model to Add Submodel
- The changes to the [Model] keyword are removed.
The Model_type Subparameters in [Model] for Dynamic_clamp and Bus_hold are
removed.
- The [Add Model] keyword name is changed to [Add Submodel]
- A new keyword [Submodel] is introduced to replace the functionality that
was added to the [Model] keyword for the old added model.
It has a new subparameter Submodel_type. Model_type is not recognized.
- [Add Model Spec] is changed to [Submodel Spec]. Kellee requested reusing
the [Model Spec] keyword, but I think it will work better with its own
specification keyword for internal details.
- The text is changed substantially, so changes are not noted.
Bob Ross
Interconnectix/Mentor Graphics
******************************************************************************
******************************************************************************
BIRD ID#: 48.4
ISSUE TITLE: Add Submodel
REQUESTER: Neven Orhanovic, Bob Ross, Mentor G., Arpad Muranyi, Intel
DATE SUBMITTED: 4/2/98, 5/1/98, 5/21/98, 5/29/98, 6/19/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:
Following the [Model Spec] keyword will be this new keyword:
|==============================================================================
| Keywords: [Add Submodel]
| Required: No
| Description: References a submodel to be added to an existing model.
| Usage Rules: The [Add Submodel] keyword is invoked within a model to
| add the functionality that is contained in the submodel or | list of submodels in each line that follows. The first
| column contains the submodel name. The second column
| contains a submodel mode under which the submodel is used.
|
| If the top-level model type is one of the I/O or 3-state
| models, the submodel mode may be Driving, Non-Driving, or
| All. For example, if the submodel mode is Non-Driving,
| then the submodel is used only in the high-Z state of a
| 3-state model. Set the submodel mode to All if the
| submodel is to be used for all modes of operation.
|
| The submodel mode cannot conflict with the top-level model
| type. For example, if the top-level model type is an
| Open or Output type, the submodel mode cannot be set to
| Non-Driving. Similarily, if the top-level model type
| type is Input, the submodel mode cannot be set to Driving.
|
| The [Add Submodel] keyword is not defined for Series or,
| Series_switch model types.
|
| Refer to the Add Submodel Description section in this
| document for the descriptions of available submodels.
|
|------------------------------------------------------------------------------
[Add Submodel]
| Submodel_name Mode
Bus_Hold_1 Non-Driving | Adds the electrical characteristics of
| [Submodel] Bus_Hold_1 for receiver or
| high-Z mode only
Dynamic_clamp_1 All | Adds the Dynmanic_clamp_1 model for
| all modes of operation
|
|==============================================================================
|=============================================================================
|=============================================================================
|
| Section 6a
|
| A D D S U B M O D E L D E S C R I P T I O N
|
|=============================================================================
|=============================================================================
|
| The [Add Submodel] keyword can be used under a top-level [Model] keyword to
| to add special-purpose functionality to the existing top-level model. This
| section describes the structure of the top-level model and the submodel.
|
| TOP-LEVEL MODEL:
|
| When special-purpose functional detail is needed, the top-level model can
| call one or more submodels. The [Add Submodel] keyword is positioned
| after the initial set of required and optional subparameters of the [Model]
| keyword and among the keywords under [Model].
|
| The [Add Submodel] keyword lists of name of each submodel and the permitted
| mode (Driving, Non-Driving or All) under which each added submodel is used.
|
| SUBMODEL:
|
| A submodel is defined using the [Submodel] keyword. It contains a subset
| of keywords and subparameters used for the [Model] keyword along with other
| keywords and subparameters that are needed for the added functionality.
|
| The [Submodel] and [Submodel Spec] keywords are defined first since they
| are used for all submodels
|
| The only required subparameter in [Submodel] is Submodel_type to define the
| list of submodel types. The other subparameters under [Model] are not
| permitted under the [Submodel] keyword.
|
| The following set of keywords that are defined under the [Model] keyword are
| support by the [Submodel] keyword:
|
| [Pulldown]
| [Pullup]
| [GND Clamp]
| [POWER Clamp]
| [Ramp]
| [Rising Waveform]
| [Falling Waveform]
|
| The [Voltage Range], [Pullup Reference], [Pulldown Reference], [GND Clamp
| Reference], and [POWER Clamp Reference] keywords are not permitted. The
| voltage settings are inherited from the top-level model.
|
| These additional keywords are used only for the [Submodel] are documented
| in this section:
|
| [Submodel Spec]
| [GND Pulse Table]
| [POWER Pulse Table]
|
| The application of these keywords depends upon the Submodel_type entries
| listed below:
|
| Dynamic_clamp
| Bus_hold
|
| Permitted keywords that are not defined for any of these submodel types are
| ignored.
|
|=============================================================================
| Keyword: [Submodel]
| Required: No
| Description: Used to define a submodel, and its attributes.
| Sub-Param: Submodel_type
| Usage Rules: Each submodel must begin with the keyword [Submodel]. The
| submodel name must match the one that is listed under the
| [Add Submodel] keyword and must not contain more than 20
| characters. A .ibs file must contain enough [Submodel]
| keywords to cover all of the model names specified under the
| [Add Submodel] keyword.
|
| Submodel_type subparameter is required and must be one of the
| following:
|
| Dynamic_clamp, Bus_hold
|
| The C_comp subparameter is not permitted under the [Submodel]
| keyword. The total effective die capacitance including the
| submodel contributions are provided in the top-level model.
|
| Other Notes: The following list of keywords that are defined under the
| [Model] keyword can be used under [Submodel]: [Pulldown],
| [Pullup], [GND Clamp], [POWER Clamp], [Ramp], [Rising
| Waveform], and [Falling Waveform].
|
| The following list of additional keywords can be used:
| [Submodel Spec], [GND Pulse Table], and [POWER Pulse Table].
|-----------------------------------------------------------------------------
[Submodel] Dynamic_clamp1
Model_type Dynamic_clamp
| variable typ min max
C_comp 1.0pF 0.5pF 1.5pF
|
|=============================================================================
|=============================================================================
| Keyword: [Submodel Spec]
| Required: No
| Description: The [Submodel Spec] keyword defines four columns under which
| specification and information subparameters are defined for
| submodels.
| Sub-Params: V_trigger_r, V_trigger_f
|
| Usage Rules: The [Submodel Spec] is to be used only with submodels
|
| 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 [Submodel 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 usually
| correspond to the values in the same colums for the inherited
| top-level voltage range or reference voltages in the top-level
| model.
|
| Unless noted, each [Submodel Spec] subparameter is independent
| of 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:
|
[Submodel 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:
|
[Submodel 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:
*** The discussion below is in terms of the older, evolving terminology ***
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.
*** The terminology below has changed to reflect the [Add Submodel] change ***
BIRD48.4 has the similar functionality as above, but in terms of a syntax
change. A [Submodel] keyword is introduced. This avoids confusing the
added model functions with the [Model] keyword.
As a result, the Model_type subparameter is not used, It is changed
to Submodel_type with arguments Dynamic_clamp, Bus_hold.
Per a comment by Kellee Chrisafulli, the list of keywords (both from [Model]
and specific for [Submodel] are listed. At the June 18, 1998 meeting, the
group discussed several issues and made these recommendations:
(1) Top-level Terminator model types should be supported since the submodel
mechanizm can be used for active terminations such as those for SCSI.
(2) The Voltages and Temperatures of the top-level model should be inherited
by the submodel. This would eliminate the need to add the corresponding
[Voltage Range] and reference voltages in the submodel. The concern is that
these can be different that what is used in the top-level model. While this
difference can lead to more generality for internal structures, it could also
lead to incompatibility with other keywords such as [Pin Mapping].
(3) C_comp is not permitted in submodels. The problem was whether submodel
cacitance should be ignored, always added to provide a total C_comp or just
added based on the [Add Submodel] mode column. Since C_comp is already an
effective capacitance for actual non-linear behavior, this detail seemed
unnecessary. The total effective capacitance positioned in one location
was the clearest solution to the problem.
(4) The allowable keywords are listed. However, the exact usage is governed
by the Submodel_type subparameter value. Consistent with the [Model] keyword,
keywords which are meaningless for a particular model type are ignored. For
example, the dynamic clamp could have the [Pullup] keyword and data, but it would not be used within a dynamic clamp submodel.
******************************************************************************
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.
BIRD48 is evolving based on subsequent IBIS meetings and reflector input.
The latest changes are based on inputs at the June 5, 1998 and June 18, 1998
IBIS meetings.
******************************************************************************
Received on Fri Jun 19 18:34:02 1998
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:29 PDT