Dear IBIS folks:
BIRD45.1 has been out for a while and there have been even some technical
suggestions for improvement. However, one suggestion was to investigate
how it could utilize the [Driver Schedule] keyword. This was investigated,
and after looking at some very complicated interactions at a meeting with
Arpad Muranyi, Bob Ross, and Chris Reid on March 11, 1998, we decided to
propose a more general and expandable mechanism that supports actual EDA
tool implementation modularization and also IBIS modularized reuse of
the existing structures when relevant. This will reduce the expansion
of keywords support every new idea that comes along.
The actual details were not discussed at that meeting. However, after some
further reflections, the [Add Model] and [Add Model Spec] keywords are
proposed here along with BIRD49 and BIRD50 for the first two implementations
The rationale is discussed within BIRD48. BIRD49 and BIRD50 are proposed
applications of the rationale for Dynamic Clamps and Bus Hold additions.
BIRD48, BIRD49, and BIRD50 are interrelated and should be considered
together.
This will be discussed at the April 3, 1998 IBIS meeting.
Bob Ross
Interconnectix/Mentor Graphics
******************************************************************************
******************************************************************************
BIRD ID#: 48
ISSUE TITLE: Add Model
REQUESTER: Neven Orhanovic, Bob Ross, Mentor G., Arpad Muranyi, Intel
DATE SUBMITTED: 4/2/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 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
|
| [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 it is 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]
| 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.
******************************************************************************
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 Thu Apr 2 14:02:30 1998
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:29 PDT