****************************************************************************** ****************************************************************************** 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: July 17, 1998 ****************************************************************************** ****************************************************************************** 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. ******************************************************************************