From owner-ibis Fri May 1 17:26:34 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id RAA11728 for ; Fri, 1 May 1998 17:26:33 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id RAA17206; Fri, 1 May 1998 17:22:54 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id RAA17717; Fri, 1 May 1998 17:22:53 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA12632; Fri, 1 May 98 17:22:52 PDT Date: Fri, 1 May 98 17:22:52 PDT Message-Id: <9805020022.AA12632@bob> To: ibis@eda.org Subject: IBIS BIRD48.1 Add Model IBIS folks: Per the April 24, 1998 meeting and some subsequent thinking, BIRD48.1 is issued to add a subparamater to describe model usage of the added model that is described by the [Model] keyword. This new, optional sub- parameter in the added model is: Add_model_mode Its parameters can be Output or Non_Output This would set the mode only for 3-state and I/O models. It would not be used for Output, Input, or Terminator models since the includion of the added model already presupposes that the added capabilty is to be used. If the optional sub-parameter Add_model_state is omitted, then the called added model is to be at all times for all [Models] called by [Add Model]. However, if the usage of the [Model] is to be restricted to either the output mode or non-output modes for either 3-state or I/O* models for which models are to be added, then the Add_model_mode subparameter describes the restriction. For example, if the model is to be used only for the high-Z or input modes of a 3-state or I/O* model, then the "Non-Output"argument would be used. BIRD48.1 also captures some changes in the [Model] keyword associated with the the [Add Model] and Add_model_mode functionality these are shown by |** lines, The changes plus some other minor editorial corrections are noted by |* lines. Bob Ross Interconnectix/Mentor Graphics ****************************************************************************** ****************************************************************************** BIRD ID#: 48.1 ISSUE TITLE: Add Model REQUESTER: Neven Orhanovic, Bob Ross, Mentor G., Arpad Muranyi, Intel DATE SUBMITTED: 4/2/98, 5/1/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. |============================================================================= | 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 a later |** 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 "Output" or "Non-Output" modes of |** 3-state or I/O models. This is described in a later 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 |** The next line is added: Add_model_mode Output | Optional for "added models" 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. | 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 |* |* A new optional subparameter is needed to define when the added [Model] |* functionality is to be used if the usage is restricted to certain modes. |* |* Add_model_mode Output | or Non-Output |* |* When Add_model_mode is omitted, or when the model that invokes the |* the [Add Model] keyword is an Input, Terminator, Series, Series_switch, or |* Output model, then Add_model_mode is not used - even if it is optonally |* provided. However, when the [Add Model] keyword is used in a 3-state |* or I/O* model, the added model works for all models of operation. |* |* However, if Add_model_mode is set to Output, the mode under which the model |* is added is restricted in 3-state and I/O* models to the output mode only. |* If the Add_model_mode is set to Non-Output, then the model under which the |* is added is restricted to the high-Z mode in 3-state models, and to the |* input mode in I/O* models. |* | [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 they are 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] |* Added 3 lines below: Add_model_mode Non-Output | The model is applied during input mode only | if the functionality is for an I/O model | | 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. 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. ****************************************************************************** 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. ****************************************************************************** From owner-ibis Fri May 1 17:27:59 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id RAA11848 for ; Fri, 1 May 1998 17:27:58 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id RAA17432; Fri, 1 May 1998 17:24:19 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id RAA17735; Fri, 1 May 1998 17:24:18 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA12635; Fri, 1 May 98 17:24:17 PDT Date: Fri, 1 May 98 17:24:17 PDT Message-Id: <9805020024.AA12635@bob> To: ibis@eda.org Subject: IBIS BIRD49.1 ADD MODEL DYNAMIC CLAMPS IBIS folks: Per the April 24, 1998 meeting and subsequent considerations, BIRD49.1 is issued so that the dynamic clamp functionality can be set by an external source. In particular, the dynamic clamp can be on before the net changes state. To accomplish this, an additional note is added regarding using a negative time with the usage [GND Pulse Table] and [POWER Pulse Table] descriptions and also the optional usage of the V_trigger_h and V_trigger_l thresholds. Changes to BIRD49 along with some editorial changes are noted by |* lines. Bob Ross Interconnectix/Mentor Graphics ****************************************************************************** ****************************************************************************** BIRD ID#: 49.1 ISSUE TITLE: Add Model Dynamic Clamps REQUESTER: Neven Orhanovic, Bob Ross, Mentor G., Arpad Muranyi, Intel DATE SUBMITTED: 4/2/98, 5/1/98 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: A novel type of termination technique is used in today's integrated circuits. The termination consists of a pair of built in dynamic clamps whose V-I curves change with time. The clamp is switched "on" when needed and switched "off" otherwise (to conserve power). When the clamp is switched "on" its V-I curve provides more clamping than a regular static clamp and when it is turned "off" it behaves like a normal clamp. The "on" switching of the dynamic clamps can be triggered by an input signal crossing a triggering threshold or by some external clock. The "off" switching can be triggered by a built in timer or an external clock. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The dynamic clamp functionality is added in the new Section 6a: | Dynamic Clamp: | | This section introduces the dynamic clamp add model functionality. Two | new keywords [GND Pulse Table] and [Power Pulse Table] are defined. Then | and example is provided for a complete dynamic clamp model. | |============================================================================= | Keyword: [GND Pulse Table], [POWER Pulse Table] | Required: No | Description: Used to dynamically specify the offset voltage of added [GND | Clamp] and [POWER Clamp] tables when the [Model] adds the | dynamic clamp functionality. | | Usage Rules: Each [GND Pulse Table] and [POWER Pulse Table] keyword | introduces a table of time vs. voltage points that describe | the shape of an offset voltage from the [GND Clamp Reference] | voltage (or default ground) or the [POWER Clamp Reference] | voltage (or default [Voltage Range] voltage). These | time/voltage points must start and end at the same value. | | The table itself | consists of one column of time points, then three columns of | voltage points in the standard typ, min, and max format. The | four entries must be placed on a single line and must be | separated by at least one white space or tab character. All | four columns are required. However, data is only required in | the typical column. If minimum or maximum data is not | available, use the reserved word "NA". The first value in the |* time column needs to be '0' or a negative value. A negative |* value denotes that the table will take the preset position at |* time "0" when the simulator pulse is initiated. The purpose |* for this is described later. Time values |* must increase as one | parses down the table. The waveform table can contain a | maximum of 100 data points. Only one [GND Pulse Table] and | one [POWER Pulse Table] are allowed per model. | | A pulse table must include the entire waveform; i.e., the | first entry (or entries) in a voltage column must be equal | to the last entry. Each table must contain at least two | entries. Thus, numerical values are required for the first | and last entries of any column containing numerical data. | | The [GND Pulse Table] and [POWER Pulse Table] keywords are used. | The subparameter under [Add Model Spec] for V_trigger_f checks | when the pulse at the die passes the trigger voltage. At that | time, the [GND Pulse Table] is invoked and the | dynamic [GND Clamp] shifts its reference by the specified | offset voltage. Similarily, the V_trigger_f subparameter gives | the voltage of the rising edge of the die at which the [POWER | Pulse Table] is invoked and the dynamic [POWER Clamp] table | begins shifting its reference by the specified offset voltage. | | A dynamic clamp is modeled by a V-I curve that is offset | (translated) along the voltage axis with the voltage waveform | given in the [GND Pulse Table] or [POWER Pulse Table] section | The resulting dynamic V-I table can be expressed as | | I = f( V - V_pulse(t) ), | | where V_pulse(t) is the offset voltage waveform described by | the pulse table and f(V) is the resulting V-I curve | of the clamp in its off state, corresponding to the data | given in the [GND Clamp] or [POWER Clamp] keyword. | | For example, once the voltage on the clamp crosses the | triggering threshold V_trigger_f, the [GND Pulse Table] data | is used to offset the V-I curve obtained | from the [GND Clamp] section. The dependence of the offset | pulse on the clamp voltage is illustrated below. | | V_trigger_f | | o o o o | o | o | o ------- | |o ^ | | o | V_trigger_f | | o v time | | o o--------------------> | | | | | | [GND Pulse Table] | | Clamp offset voltage vs. time. | | | | o o o o | | o o | | o o | | o o | | o o | | o o time | o o o o o o o o --------> | | ^ | |_ Pulse data is used from this moment on | to offset the V-I curve. | | The V_trigger_r and [POWER Pulse Table] operate in a similar manner. | However, offset voltage which fall into the normal operation region are | given by negative voltage values. |* |* A mode of operation that does not depend on the V_trigger_f or V_trigger_r |* is described next. The intent is to allow the simulation of the dynamic |* clamp effect when the dynamic clamp operation is controlled by an external |* control signal to activate it prior to when the signal on the net arrives. |* |* When either the [GND Pulse Table] or [POWER Pulse Table] pulse begin with |* a time value less than '0', its operation is under these rules. The |* voltage setting at the first negative time value denotes a voltage offset |* value before the dynamic clamp is turned on. The voltage value at time |* 'O' is the value at the time the simulation output pulse of a positive |* or a negative polarity is initiated. If the simulation pulse is of a |* positive polarity for a driver change from the low to the high state, |* the [POWER Clamp Table] is "initialized" to the voltage value at time '0'. |* Similarily, if the simulation pulse is of a negative polarity for a |* driver change from the high to the low state, the [GND Clamp Table] is |* "initialized to the voltage value at time '0'. |* |* The corresponding V_trigger_r or V_trigger_l subparameter is ignored and |* may be omitted. |------------------------------------------------------------------------------ | *| Example of Dynamic_clamp Model with both dynamic GND and POWER clamps: | [Model] Dynamic_Clamp_1 Model_type Dynamic_clamp C_comp 0 0 0 | [Add Model Spec] | Subparameter typ min max | V_trigger_f 1.4 1.2 1.6 | Falling edge trigger V_trigger_r 3.6 2.9 4.3 | Rising edge trigger | [GND Pulse Table] | GND Clamp offset table | Time V(typ) V(min) V(max) | | 0 0 0 0 | 1e-9 0 0 0 | 2e-9 0.9 0.8 1.0 | 10e-9 0.9 0.8 1.0 | 11e-9 0 0 0 | [GND Clamp] | Table to be offset | | Voltage I(typ) I(min) I(max) | -5.000 -3.300e+01 -3.000e+01 -3.500e+01 -4.000 -2.300e+01 -2.200e+01 -2.400e+01 -3.000 -1.300e+01 -1.200e+01 -1.400e+01 -2.000 -3.000e+00 -2.300e+00 -3.700e+00 -1.900 -2.100e+00 -1.500e+00 -2.800e+00 -1.800 -1.300e+00 -8.600e-01 -1.900e+00 -1.700 -6.800e-01 -4.000e-01 -1.100e+00 -1.600 -2.800e-01 -1.800e-01 -5.100e-01 -1.500 -1.200e-01 -9.800e-02 -1.800e-01 -1.400 -7.500e-02 -7.100e-02 -8.300e-02 -1.300 -5.750e-02 -5.700e-02 -5.900e-02 -1.200 -4.600e-02 -4.650e-02 -4.550e-02 -1.100 -3.550e-02 -3.700e-02 -3.450e-02 -1.000 -2.650e-02 -2.850e-02 -2.500e-02 -0.900 -1.850e-02 -2.100e-02 -1.650e-02 -0.800 -1.200e-02 -1.400e-02 -9.750e-03 -0.700 -6.700e-03 -8.800e-03 -4.700e-03 -0.600 -3.000e-03 -4.650e-03 -1.600e-03 -0.500 -9.450e-04 -1.950e-03 -3.650e-04 -0.400 -5.700e-05 -2.700e-04 -5.550e-06 -0.300 -1.200e-06 -1.200e-05 -5.500e-08 -0.200 -3.000e-08 -5.000e-07 0.000e+00 -0.100 0.000e+00 0.000e+00 0.000e+00 0.000 0.000e+00 0.000e+00 0.000e+00 5.000 0.000e+00 0.000e+00 0.000e+00 | [POWER Pulse Table] | POWER Clamp offset table | | Time V(typ) V(min) V(max) | | 0 0 0 0 | 1e-9 0 0 0 | 2e-9 -0.9 -1.0 -0.8 | 10e-9 -0.9 -1.0 -0.8 | 11e-9 0 0 0 | [POWER Clamp] | Table to be offset | | Voltage I(typ) I(min) I(max) | -5.000 1.150e+01 1.100e+01 1.150e+01 -4.000 7.800e+00 7.500e+00 8.150e+00 -3.000 4.350e+00 4.100e+00 4.700e+00 -2.000 1.100e+00 8.750e-01 1.300e+00 -1.900 8.000e-01 6.050e-01 1.000e+00 -1.800 5.300e-01 3.700e-01 7.250e-01 -1.700 2.900e-01 1.800e-01 4.500e-01 -1.600 1.200e-01 6.850e-02 2.200e-01 -1.500 3.650e-02 2.400e-02 6.900e-02 -1.400 1.200e-02 1.100e-02 1.600e-02 -1.300 6.300e-03 6.650e-03 6.100e-03 -1.200 4.200e-03 4.750e-03 3.650e-03 -1.100 2.900e-03 3.500e-03 2.350e-03 -1.000 1.900e-03 2.450e-03 1.400e-03 -0.900 1.150e-03 1.600e-03 7.100e-04 -0.800 5.500e-04 9.150e-04 2.600e-04 -0.700 1.200e-04 4.400e-04 5.600e-05 -0.600 5.400e-05 1.550e-04 1.200e-05 -0.500 1.350e-05 5.400e-05 1.300e-06 -0.400 8.650e-07 7.450e-06 4.950e-08 -0.300 6.250e-08 7.550e-07 0.000e+00 -0.200 0.000e+00 8.400e-08 0.000e+00 -0.100 0.000e+00 0.000e-08 0.000e+00 0.000 0.000e+00 0.000e+00 0.000e+00 | |============================================================================== ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: The proposal is designed to retain as much of the existing IBIS clamp syntax as possible. The dynamic clamp V-I curve tables follow all of the conventions of the existing V-I tables. The overall modeling approach is to decompose the dynamic clamp into its static and dynamic portions. The static part can be modeled by a regular clamp. The dynamic part is connected to the same rail voltage as its static part and modeled by a V-I curve that is shifted along the voltage axis by the offset voltage pulse. BIRD49 replaces the BIRD45.1 proposal of some new keywords shown below, but preserves the intended functionality. It also reponses to the comment that some of the V_trigger subparameters should be expressed in a typ-min-max format. The [Model Spec] keyword structure is proposed to do this. The replaced structure is below. |============================================================================== | Keywords: [Dynamic GND Clamp], [Dynamic POWER Clamp] | Required: No. | Description: Describes ground and power clamps that are switched on and off | dynamically. | | Subparameters: V_trigger, V_trigger_min, V_trigger_max | | Usage Rules: The [Dynamic GND Clamp] and [Dynamic PWR Clamp] specifications | contain three subparameters and two keywords. The subparameters | (V_trigger, V_trigger_min, V_trigger_max) specify the threshold | clamp voltage value that causes the clamp to begin switching | from "off" to "on" according to the [Pulse Table] section. | These values correspond to the typical, weak (slow), and strong | (fast) situations. The [Pulse Table] section describes the | switching characteristics of the dynamic clamp, and the [Clamp | Table] section gives the V-I table of the clamp in its "off" | state. This data is used as follows. | | A dynamic clamp is modeled by a V-I curve that is offset | (translated) along the voltage axis with the voltage waveform | given in the [Pulse Table] section. The resulting dynamic V-I | curve can be expressed as | | I = f( V - V_pulse(t) ), | | where V_pulse(t) is the offset voltage waveform described by | the [Pulse Table] section and f(V) is the resulting V-I curve | of the clamp in its off state, corresponding to the data | given in the [Clamp Table] section. The [Clamp Table] data | follows the same format and rules as the V-I curve data of | the corresponding regular ground or power clamp ([GND Clamp], | [POWER Clamp]). The [Pulse Table] section describes the offset | voltage waveform and uses the same format as the [Rising | Waveform] and [Falling Waveform] sections in driver models. | | Once the voltage on the clamp crosses the triggering threshold, | the [Pulse Table] data is used to offset the V-I curve obtained | from the [Clamp Table] section. The dependence of the offset | pulse on the clamp voltage is illustrated below. | | | Clamp voltage vs. time. | | o o o o | o | o | o ------- | o| ^ | o | | V_trigger | o | v time | o o | ------------------------> | | | | | | | | Clamp offset voltage vs. time. | | | | o o o o | | o o | | o o | | o o o o o | | o o | | o o time | o o o o o o o o --------> | | ^ | |_ Pulse data is used from this moment on | to offset the V-I curve. | | |------------------------------------------------------------------------------ | | Example: | [Dynamic GND Clamp] | V_trigger = 1.4V V_trigger_min = 1.2V V_trigger_max = 1.6V | [Pulse Table] | | Time V(typ) V(min) V(max) | | 0 0 0 0 | 1e-9 0 0 0 | 2e-9 0.9 0.8 1.0 | 10e-9 0.9 0.8 1.0 | 11e-9 0 0 0 | [Clamp Table] | | Voltage I(typ) I(min) I(max) | -5.000 -3.300e+01 -3.000e+01 -3.500e+01 -4.000 -2.300e+01 -2.200e+01 -2.400e+01 -3.000 -1.300e+01 -1.200e+01 -1.400e+01 -2.000 -3.000e+00 -2.300e+00 -3.700e+00 -1.900 -2.100e+00 -1.500e+00 -2.800e+00 -1.800 -1.300e+00 -8.600e-01 -1.900e+00 -1.700 -6.800e-01 -4.000e-01 -1.100e+00 -1.600 -2.800e-01 -1.800e-01 -5.100e-01 -1.500 -1.200e-01 -9.800e-02 -1.800e-01 -1.400 -7.500e-02 -7.100e-02 -8.300e-02 -1.300 -5.750e-02 -5.700e-02 -5.900e-02 -1.200 -4.600e-02 -4.650e-02 -4.550e-02 -1.100 -3.550e-02 -3.700e-02 -3.450e-02 -1.000 -2.650e-02 -2.850e-02 -2.500e-02 -0.900 -1.850e-02 -2.100e-02 -1.650e-02 -0.800 -1.200e-02 -1.400e-02 -9.750e-03 -0.700 -6.700e-03 -8.800e-03 -4.700e-03 -0.600 -3.000e-03 -4.650e-03 -1.600e-03 -0.500 -9.450e-04 -1.950e-03 -3.650e-04 -0.400 -5.700e-05 -2.700e-04 -5.550e-06 -0.300 -1.200e-06 -1.200e-05 -5.500e-08 -0.200 -3.000e-08 -5.000e-07 0.000e+00 -0.100 0.000e+00 0.000e+00 0.000e+00 0.000 0.000e+00 0.000e+00 0.000e+00 5.000 0.000e+00 0.000e+00 0.000e+00 | | [Dynamic POWER Clamp] | V_trigger = 3.6V V_trigger_min = 3.8V V_trigger_max = 3.4V | [Pulse Table] | | Time V(typ) V(min) V(max) | | 0 0 0 0 | 1e-9 0 0 0 | 2e-9 -0.9 -1.0 -0.8 | 10e-9 -0.9 -1.0 -0.8 | 11e-9 0 0 0 | [Clamp Table] | | Voltage I(typ) I(min) I(max) | -5.000 1.150e+01 1.100e+01 1.150e+01 -4.000 7.800e+00 7.500e+00 8.150e+00 -3.000 4.350e+00 4.100e+00 4.700e+00 -2.000 1.100e+00 8.750e-01 1.300e+00 -1.900 8.000e-01 6.050e-01 1.000e+00 -1.800 5.300e-01 3.700e-01 7.250e-01 -1.700 2.900e-01 1.800e-01 4.500e-01 -1.600 1.200e-01 6.850e-02 2.200e-01 -1.500 3.650e-02 2.400e-02 6.900e-02 -1.400 1.200e-02 1.100e-02 1.600e-02 -1.300 6.300e-03 6.650e-03 6.100e-03 -1.200 4.200e-03 4.750e-03 3.650e-03 -1.100 2.900e-03 3.500e-03 2.350e-03 -1.000 1.900e-03 2.450e-03 1.400e-03 -0.900 1.150e-03 1.600e-03 7.100e-04 -0.800 5.500e-04 9.150e-04 2.600e-04 -0.700 1.200e-04 4.400e-04 5.600e-05 -0.600 5.400e-05 1.550e-04 1.200e-05 -0.500 1.350e-05 5.400e-05 1.300e-06 -0.400 8.650e-07 7.450e-06 4.950e-08 -0.300 6.250e-08 7.550e-07 0.000e+00 -0.200 0.000e+00 8.400e-08 0.000e+00 -0.100 0.000e+00 0.000e-08 0.000e+00 0.000 0.000e+00 0.000e+00 0.000e+00 | |============================================================================== BIRD49.1 adds the rules for when the time is negative and when the V_trigger_l and V_trigger_h thresholds are not used and can be omitted. The intent is to support having the dynamic clamps controlled by an external control so that they can be preset before the signal arrives at the device. A method was chosen that is based on the activation pulse that the simulator uses to initiate the driver transition. Most simulators do not have an independent pulse control to preset some other parameter. This method can be user configurable to deal with simulator differences in time relationships for driver activation on the net and possible phase differences of this component on a net. The time values may have to be readjusted for a particular part. However, the approach taken here should work for most practical cases. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: Based on a conversation with Arpad Muranyi on 11/14/97. Modified per a discussion with Bob Ross, Chris Reid and Arpad Muranyi on March 11, 1998. ****************************************************************************** From owner-ibis Fri May 1 17:29:16 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id RAA11855 for ; Fri, 1 May 1998 17:29:16 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id RAA17460; Fri, 1 May 1998 17:25:37 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id RAA17747; Fri, 1 May 1998 17:25:35 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA12638; Fri, 1 May 98 17:25:35 PDT Date: Fri, 1 May 98 17:25:35 PDT Message-Id: <9805020025.AA12638@bob> To: ibis@eda.org Subject: IBIS BIRD51 3-STATE_ECL IBIS folks: BIRD51 adds the 3-state_ECL Model type. A few ECL devices are designed with a true high-Z mode. Bob Ross Interconnectix/Mentor Graphics ****************************************************************************** ****************************************************************************** BIRD ID#: 51 ISSUE TITLE: 3-state_ECL REQUESTER: Bob Ross, Mentor Graphics DATE SUBMITTED: 5/1/98 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: A true 3-state ECL device cannot be described correctly using IBIS. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The [Model] keyword is shown with changes indicated by the |* lines below: |============================================================================== | 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, 3-state_ECL, Terminator, |* Series, and Series_switch. | | 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] |* 3-state_ECL 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 | | 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 | |============================================================================= In the NOTES ON DATA DERIVATION Section, change section 3b) for Ramp Rates to read (Change noted by the |* line): | 3) Ramp Rates: | The following steps assume that the default load resistance of 50 ohms is | used. There may be models that will not drive a load of only 50 ohms | into any useful level of dynamics. In these cases, use the semiconductor | vendor's suggested (nonreactive) load and add the load subparameter to | the [Ramp] specification. | | The ramp rate does not include packaging but does include the effects of | the C_comp parameter; it is the intrinsic output stage rise and fall time | only. | | The ramp rates (listed in AC characteristics below) should be derived as | follows: | | a. If starting with the silicon model, remove all packaging. If starting | with a packaged model, perform the measurements as outlined below. | Then use whatever techniques are appropriate to derive the actual, | unloaded rise and fall times. | | b. If: The Model_type is one of the following: Output, I/O, or 3-state | (not open or ECL types); | Then: Attach a 50 ohm resistor to GND to derive the rising edge | ramp. Attach a 50 ohm resistor to POWER to derive the | falling edge ramp. | |* If: The Model_type is Output_ECL, I/O_ECL, 3-state_ECL; | Then: Attach a 50 ohm resistor to the termination voltage | (Vterm = VCC - 2 V). Use this load to derive both the | rising and falling edges. | | If: The Model_type is either an Open_sink type or Open_drain type; | Then: Attach either a 50 ohm resistor or the semiconductor vendor | suggested termination resistance to either POWER or the | suggested termination voltage. Use this load to derive both | the rising and falling edges. | | If: The Model_type is an Open_source type; | Then: Attach either a 50 ohm resistor or the semiconductor vendor | suggested termination resistance to either GND or the | suggested termination voltage. Use this load to derive both | the rising and falling edges. | ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: The National Semiconductor 100316 has true 3-state_ECL pins. Several other ECL devices with a true high-Z state also exist. They currently have to be described incorrectly as Output_ECL models - ignoring the high impedance state, or as I/O_ECL models - requiring incorrect Vinl and Vinh threshold information which would not be used. The only correct solution is proposed in BIRD51 to define the new 3-state_ECL model type ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: Tom Dagostino for pointing out the problem devices and the need for the IBIS IBIS document to include the 3-state_ECL model type. ****************************************************************************** From owner-ibis Thu May 7 09:40:10 1998 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id JAA17771 for ; Thu, 7 May 1998 09:40:08 -0700 (PDT) Received: from sbuamazko2ae.zko.dec.com (sbuamazko2ae.zko.dec.com [16.29.160.92]) by mail13.digital.com (8.8.8/8.8.8/WV1.0e) with ESMTP id MAA17888 for ; Thu, 7 May 1998 12:36:58 -0400 (EDT) Received: by sbuamazko2ae.zko.dec.com with Internet Mail Service (5.0.1458.49) id ; Thu, 7 May 1998 12:37:06 -0400 Message-ID: <71EEA9EA5129D1118EA30000F840EBF15379F1@sbuamapko3bc.eng.pko.dec.com> From: Greg Edlund To: "'ibis@vhdl.org'" Cc: "Breda, Kathy" , "Chang, Vincent" , "Edlund, Greg" , "Engelmann, Fawn" , "Fitzgerald, Greg" , "Haller, Robert" , "Heilbrunn, Bruce" , "LaFlamme, Peter" , "Ross, Bob" , "Sayre, Ed" , "Stiegler, Harvey" Subject: IBIS Accuracy Subcommittee Minutes 4/30/98 Date: Thu, 7 May 1998 12:27:48 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain; charset="iso-8859-1" IBIS Accuracy Subcommittee Minutes Thursday, April 30, 1998 Held at Digital Equipment's PKO3 building, 129 Parker St., Maynard, MA Attendees Greg Edlund, Digital Equipment (chair) Fawn Engelmann, EMC Bob Haller, Digital Equipment Bruce Heilbrunn, Stratus Computer Peter LaFlamme, Fairchild Semiconductor Next meeting is Thursday, May 21, 1998 from 3:00 to 5:00 pm at Digital Equipment's PKO3 building, 129 Parker St., Maynard, MA. MILESTONES The test board milestone has slipped. Greg and Fawn report difficulty making progress on the board due to busy schedules. June, 1998: Post the IBIS Model Test Board to the web September 18, 1998: Distribute the first draft of the IBIS Accuracy Specification October 1998: PCB West Conference, IBIS Summit, and first IBIS Class February 1999: Present the IBIS Accuracy Specification at DesignCon99 EDITING 1. Scope The subcommittee voted unanimously to adopt a limited scope for the IBIS Accuracy Specification version 1 as defined by the following keywords and sub-parameters: [Package] R_pkg, L_pkg, C_pkg [Pin] R_pin, L_pin, C_pin [Model] C_comp, Input, Output, I/O, 3-state, Open_drain [Pulldown] [Pullup] [GND_clamp] [POWER_clamp] [Ramp] dV/dt_r, dV/dt_f On April 8, 1998, three members of the IBIS Accuracy Sub-Committee - Bruce Heilbrunn, Bob Haller, and Greg Edlund - met with Paul Back of 3Com at Stratus Computer in Marlboro to discuss the scope of the IBIS Accuracy Specification and appropriate test loads. Paul is a former Stratus employee and has brought his experience with behavioral modeling and simulation to the IBIS Users Group. Thanks to Bruce Heilbrunn and Stratus for hosting the meeting. Most of the differences in opinion were really differences in language. At Stratus and 3Com, they use the term "model generation" to mean extracting behavioral models from SPICE simulations. Their process uses a resistive load whose value is tailored to the output impedance of the driver. The term "validation" describes the process of comparing SPICE and behavioral simulations for a variety of system-like test loads. There is a significant difference between the Stratus process and IBIS at this point. For "validation," Stratus likes to use a range of test loads between 10 and 100 Ohms. IBIS is content with a typical 50 Ohm load. The "Digital camp" and the "Stratus camp" agreed on one thing: the set of test loads that are required to cover a given driver's electrical behavior is definitely dependent on the design of the driver. One can think of this problem as analogous to the ASIC fault coverage problem; the test engineer needs to come up with a set of test vectors that will cover the known faults for a given ASIC technology. In the same manner, the writers of the IBIS Accuracy Specification need to come up with a set of measurements that cover the known electrical behavior of a given I/O buffer family. Greg gave the example of the GTL output buffer, which employs a feedback circuit to adjust the output edge rate as a function of load impedance. Clearly, an IBIS datasheet for a GTL driver that was verified at 50 Ohms may not be valid at other load impedances. This is the compromise that we arrived at: the first release of the IBIS Accuracy Specification will cover the I/O buffer families covered by IBIS 1.1, namely push-pull, open-drain, and open-collector. Bruce Heilbrunn has been concerned that the first incarnation of the IBIS Accuracy Specification may not be usable for other more advanced I/O buffer families. To address this concern, we propose adding a disclaimer statement to the scope section of the document: "The methods defined by this specification may be used with unspecified I/O buffers families, although this specification makes no attempt to insure coverage of their electrical behavior by the measurements and metrics defined within this specification." The next version of the IBIS Accuracy Specification will by necessity address the thorny issue of advanced driver families and differences among simulation engines. Accuracy Levels The subcommittee defined four levels of accuracy which are intended to cover a wide range of user needs. Each accuracy level corresponds to the availability of different kinds of test samples. The methods of comparing test data against behavioral simulation data are dependent on what kind of test sample is available. We make reference below to two lab vs. simulation comparison metrics, which will be clearly defined when we write section 4 of the specification. In summary, metric 1 attempts to overlay two curves and quantify the average distance between corresponding data points on the curves in the x or y direction. Metric 2 measures whether one curve fits within the envelope defined by two other curves that represent process and temperature extremes. Level 1 is the most accurate and is applicable when a vendor has the capability of tweaking the process variables to achieve what he or she believes to represent the typical, extreme fast, and extreme slow conditions. He then runs behavioral simulations which utilize the typ/min/max columns in the IBIS datasheet. In theory, the behavioral waveforms should overlay the lab waveforms closely because the process conditions are known, and metric 1 (average absolute percent error) quantifies the discrepancies Level 2 is useful when a vendor has samples that are known to have been processed in a typical lot but does not have the capability or luxury of processing corner silicon. Using metric 1, the vendor compares the lab data with behavioral simulations based on only the typ column of the IBIS datasheet. In the absence of corner silicon, the vendor compares SPICE waveforms at fast and slow process corners with behavioral simulations at min and max datasheet columns also using metric 1. The fast and slow SPICE waveforms serve as a stand-in in for real lab data. The vendor must rely on the capabilities of his device modeling engineers to produce transistor model parameters that are in keeping with the limits imposed by statistical process control. We expect level 2 to be the most commonly used. Level 3 is useful when a vendor has accurate SPICE models available but does not know the processing conditions of the lot from which his sample part came, i.e. the part is a "random sample." He uses metric 1 to compare behavioral and SPICE waveforms at all three corners but uses metric 2 (envelope) to compare lab data to behavioral data. Metric 2 works well for IV curves and terminated loads, but it is not true that the min and max waveforms will completely envelop all other waveforms in the case of the unterminated transmission line. Level 4 is useful when only a random sample is available. It may be used by third-party model vendors who do not have access to SPICE models. This level may also be valid for a customer who is seeking to validate a semiconductor vendor's IBIS datasheet with no other data available. It is probably not of much use to semiconductor vendors since they have SPICE models available. Note that there is no accuracy level defined for comparing IBIS and SPICE data only. While metric 1 may be valuable for checking SPICE vs. IBIS during model generation, this approach does not fit the definition of accuracy, which involves comparing experiment (lab) and theory (simulation). Lab measurements are an absolute necessity for insuring the accuracy of an IBIS datasheet. 2. Required Measurements The subcommittee approved of a first-cut at the required test loads for push-pull drivers. These will appear in schematic form when we write the specification. The required test loads for a push-pull driver are as follows: vendor-defined standard load 50 Ohms to Gnd (or 50 Ohm transmission line terminated by 50 Ohms to Gnd) 50 Ohms to Vdd (or 50 Ohm transmission line terminated by 50 Ohms to Vdd) open-ended transmission line, length a function of rise time driver driving receiver through a transmission line The required test loads for an open-drain driver are as follows: vendor-defined standard load 50 Ohms to Vtt (or 50 Ohm transmission line terminated by 50 Ohms to Vtt) open-ended transmission line terminated to Vtt at the near end, length a function of rise time driver driving receiver through a transmission line terminated to Vtt at the near end All of the push-pull test loads appear on the IBIS Accuracy Test Board. At the next meeting we need to discuss the other required measurements: IV curves and capacitance. There was some discussion regarding the need for 10 Ohm and 100 Ohm loads in addition to the 50 Ohm loads. Bob Haller argued that for the drivers he's worked with, if correlation is good at 50 Ohms, it will be good at other load impedances as well. Bruce Heilbrunn argued that there are drivers that correlate well at 50 Ohms but not at the extremes of load impedance. Bruce has the task of finding an example of an IBIS 1.1 driver that exhibits good correlation at 50 Ohms and poor correlation at the extremes. 3. Measurement Techniques We did not discuss measurement techniques at this meeting. The June and July meetings will be dedicated to this topic. 4. Metrics We did not discuss comparison metrics at this meeting. The August meeting will be dedicated to this topic. RELATED ACTIVITIES IBIS Accuracy Test Board - Fawn and Greg have finished the schematics for rev 2 of the accuracy test board and are now into layout. It looks like it will be sometime in June before we have debugged hardware in hand and are ready to release the design to the world. There have been some people who expressed an interest in the board for training purposes. IBIS Developers Tool Kit - We received positive response from the following vendors regarding their plans for making available a free or low-cost simulation engine for model development purposes: HyperLynx, Mentor/Interconnectix, Quad Design, and Cadence. Thanks to all for their cooperation. We realize that it takes time to create such software, especially when it is not a part of a product offering. IBIS Cookbook - We did not report any progress on the cookbook. We expect this activity to pick up when we get further into the measurement techniques section. HOMEWORK Greg Edlund - Finish layout of the IBIS Accuracy Test Board. Fawn Engelmann - Finish layout of the IBIS Accuracy Test Board. Bob Haller - capture all required measurements in Word. Bruce Heilbrunn - Identify a component that would serve as an example of an IBIS 1.1 driver that exhibits good correlation at 50 Ohms and poor correlation at the extremes. Demonstrate the magnitude of the discrepancies between SPICE and behavioral simulations. Peter LaFlamme - Identify and procure SPICE models for a component that would serve as an example of an IBIS 1.1 open-drain driver. ---------- Greg Edlund, Principal Engineer Server Product Development Digital Equipment Corp. 129 Parker St. PKO3-1/20C Maynard, MA 01754 (978) 493-4157 voice (978) 493-0941 FAX greg.edlund@digital.com From owner-ibis Thu May 7 18:12:28 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id SAA25122 for ; Thu, 7 May 1998 18:12:27 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id SAA02750; Thu, 7 May 1998 18:08:36 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id SAA11508; Thu, 7 May 1998 18:08:24 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA17050; Thu, 7 May 98 18:08:24 PDT Date: Thu, 7 May 98 18:08:24 PDT Message-Id: <9805080108.AA17050@bob> To: ibis@eda.org Subject: IBIS Version 3_1c.ibs All: An unofficial work in progress IBIS Version 3.1 file is uploaded as http://www.eda.org/pub/ibis/wip/ver3_1c.ibs It contains the approved BIRD47 change. Bob Ross Interconnectix/Mentor Graphics From owner-ibis Fri May 8 10:15:56 1998 Received: from thinkpad.qdt.com (root@ppp-209-79-182-145.vntrcs.pacbell.net [209.79.182.145]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id KAA10084 for ; Fri, 8 May 1998 10:15:55 -0700 (PDT) Received: from thinkpad.qdt.com (localhost [127.0.0.1]) by thinkpad.qdt.com (8.8.5/8.8.5) with SMTP id KAA02480 for ; Fri, 8 May 1998 10:10:28 -0700 Sender: root@thinkpad.qdt.com Message-ID: <35533C83.32A84270@pacbell.net> Date: Fri, 08 May 1998 10:10:27 -0700 From: jon powell Organization: viewlogic X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.30 i586) MIME-Version: 1.0 To: ibis@vhdl.org Subject: Model Page Update Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Fellow Ibisians, It has been brought to my attention (OK, Bob yelled at me) that the ibis model pages is in need of some updates and upgrades. I have just finished a pass to that end. The existing links have been corrected and tested and some additional links have been added. I will be doing some research to add additional sites. If you know of any sites that I am missing, please send me some email. thanks Jon Powell IBIS Librarian. (an unpaid position) From owner-ibis Fri May 8 11:54:04 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id LAA11645 for ; Fri, 8 May 1998 11:54:03 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id LAA00458; Fri, 8 May 1998 11:50:11 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id LAA16595; Fri, 8 May 1998 11:49:58 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA17517; Fri, 8 May 98 11:49:58 PDT Date: Fri, 8 May 98 11:49:58 PDT Message-Id: <9805081849.AA17517@bob> To: ibis@eda.org Subject: IBIS Meeting 5/15/98 IBIS Open Forum Meeting Agenda for 5/15/98 Bridge Number Reservation # Passcode (916) 356-9200 4-167409 2939394 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Rusher - Review of Previous Meeting's Minutes (and ARs) Peters - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Powell, All - Opens for New Issues All 8:25 Administrative and Project Discussions International/External Progress Rusher/Ross - IEC 62014-1 (IBIS Version 2.1) - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) - 93/67/NP IBIS and EMC Simulation Perrin - JC-16B Sessions IBIS (East) Users Group Meetings Edlund IBIS Logo Change Vote Rusher/Ross Editing Committee Ross/Peters BIRD44 - Interpretation of Min/Max/Weak/Strong Data Ross IBISCHK2+ (Ver 2.115) PROGRESS Flora/Rokusek BUG28 - Line with 80 Spaces Cause Crash Rokusek Version 3.1 Parser Development Ross/Peters - Billing - Tests & Samples Cookbook Status Peters IBIS Model Review Committee Flora New Administrative Issues All 9:15 Technical Discussion BIRD42.3 - Modeling Current Waveforms Kumar/Ross BIRD48.1 - Add Model Orhanovic/Muranyi/Ross BIRD49.1 - Add Model Dynamic Clamps Orhanovic/Muranyi/Ross BIRD50 - Add Model Bus Hold Orhanovic/Muranyi/Ross BIRD46.1 - Relaxation of Some IBIS Model File Name Flora Restrictions BIRD51 - 3-state_ECL Ross New Technical Issues All 9:50 Wrap Up and Next Meetings Plans Ross 9:55 Sign Off From owner-ibis Mon May 11 11:45:49 1998 Received: from mail-gw3.pacbell.net (mail-gw3.pacbell.net [206.13.28.55]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id LAA14080 for ; Mon, 11 May 1998 11:45:48 -0700 (PDT) Received: from pacbell.net (ppp-209-79-182-202.vntrcs.pacbell.net [209.79.182.202]) by mail-gw3.pacbell.net (8.8.8/8.7.1+antispam) with ESMTP id LAA04034; Mon, 11 May 1998 11:42:33 -0700 (PDT) Message-ID: <35574537.8AB93679@pacbell.net> Date: Mon, 11 May 1998 11:36:40 -0700 From: Jon Powell Reply-To: jonp@qdt.com Organization: Viewlogic Consulting Services X-Mailer: Mozilla 4.04 [en]C-PBI-NC404 (Win95; I) MIME-Version: 1.0 To: ibis@vhdl.org Subject: IBIS model page update Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hey again, The IBIS model page has been updated with feedback from various persons. A few new site listing and I fixed the spelling of "whant". (it should have been wqant). check it out: http://www.fishnet.net/~qdt/ibis/models.htm From owner-ibis Mon May 11 12:01:56 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id MAA14366 for ; Mon, 11 May 1998 12:01:55 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id LAA11921; Mon, 11 May 1998 11:58:03 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id LAA03712; Mon, 11 May 1998 11:57:49 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA19368; Mon, 11 May 98 11:57:50 PDT Date: Mon, 11 May 98 11:57:50 PDT Message-Id: <9805111857.AA19368@bob> To: ibis@eda.org Subject: IBIS Uploads To All: The PRELIMINARY compressed ibischk3 and ebdchk3 executables for Unix and DOS32 systems have been uploaded to eda.org under /pub/ibis/ibischk3/ Thanks to Chris Rokusek for generating them. Also, the Power Point presentations for the TC93WG6 Task Group Experts Meeting on EMC and IBIS Simulation held on February 27, 1998 in Paris, sent by Jean Claude Perrin, are uploaded under /pub/ibis/wip/wg6part.zip Bob Ross Interconnectix/Mentor Graphics From owner-ibis Mon May 11 12:47:04 1998 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id MAA14951 for ; Mon, 11 May 1998 12:47:03 -0700 (PDT) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id MAA17429 for ; Mon, 11 May 1998 12:59:06 -0700 (PDT) Received: from xtg801 (xtg801.pdx.intel.com [134.134.120.169]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id MAA02153 for ; Mon, 11 May 1998 12:43:51 -0700 (PDT) Received: from ichips.intel.com by xtg801 (8.8.8/WW2.1 (Jones Farm)) id MAA20940; Mon, 11 May 1998 12:43:50 -0700 (PDT) Message-Id: <199805111943.MAA20940@xtg801> X-Mailer: exmh version 2.0delta 6/3/97 To: ibis@eda.org Subject: Re: Forwarded: IBISCHK3 and EBDCHK3 Executables. In-reply-to: Your message of "Mon, 11 May 1998 11:35:36 PDT." <9805111835.AA19328@bob> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 11 May 1998 12:43:48 -0700 From: Stephen Peters Bob Ross wrote: > Chris: > > Thank you for the executables. They have been uploaded on eda.org > under /pub/ibis/ibischk3 in compressed form along with some > DOS32 executables. > > Regarding combining the executables, I would not have a problem > with this and making the -ebd extension for .ebd files, if needed. > The EBD files require the .ebd extension. > > It is up to Atul for ease of managing the develoment of the programs. > > Comments anyone? > > Best Regards, > Bob > Having one executable seems a good idea, given the above conditions. Regards, Stephen Peters Intel Corp. From owner-ibis Tue May 12 06:20:20 1998 Received: from chekov.Belgium.eu.net (relay.eunet.be [192.92.130.25]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id GAA01247 for ; Tue, 12 May 1998 06:20:18 -0700 (PDT) Received: from (windsor.agfa.be [193.74.21.1]) by chekov.Belgium.eu.net with SMTP id PAA22313 for ; Tue, 12 May 1998 15:16:38 +0200 (MET DST) Received: from halifax (halifax.roam.agfa.be) by agfa.be (4.1/SMI-4.1) id AA12931; Tue, 12 May 98 15:15:50 +0200 Received: from diamant1.agfa.be by halifax (SMI-8.6/SMI-SVR4) id PAA04555; Tue, 12 May 1998 15:15:45 +0200 Received: by diamant1.agfa.be (5.x/SMI-SVR4) id AA15222; Tue, 12 May 1998 15:15:43 +0200 Date: Tue, 12 May 1998 15:15:43 +0200 From: jvercamm@roam.agfa.be (Jan Vercammen) Message-Id: <9805121315.AA15222@diamant1.agfa.be> To: ibis@vhdl.org Subject: ibis files on crystal clock generators X-Sun-Charset: US-ASCII hello, could someone provide me with the coordinates of a site(s) were I could find IBIS files on crystal clock generators (no PLLs or buffers, just 4 pin devices). Your help is appreciated. regards, jan vercammen EMC engineer Agfa-Gevaert From owner-ibis Wed May 13 11:24:11 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id LAA28449 for ; Wed, 13 May 1998 11:24:10 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id LAA19376; Wed, 13 May 1998 11:20:17 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id LAA23293; Wed, 13 May 1998 11:20:03 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA20849; Wed, 13 May 98 11:20:04 PDT Date: Wed, 13 May 98 11:20:04 PDT Message-Id: <9805131820.AA20849@bob> To: ibis@eda.org Subject: Forwarded: EIAJ I/O Interface Model To IBIS Team: This is being forwarded for your information. Several of us met with Fukuda-san last year. The Outline of I/O Interface Project Group is new. Bob Ross Interconnectix/Mentor Graphics Date: Wed, 13 May 98 21:39:14 +0900 From: "Hideki-ULSI Fukuda" To: Subject: EIAJ I/O Interface Model Bob-san How are you? I have not talked with you in a long time. I hope everything is going well. We just opened our home page. You can see there our activities in EIAJ standardization and drafts of EIAJ I/O Interface Model. The URL is http://tsc.eiaj.or.jp If you have any trouble in reading or printing the traft, please let me know. We consumed long time to eliminate troubles since this is the first experience for us to open home page. I have been very busy because my company merged another subsidiary company of Hitachi on April 1. My title in the company, the name of the new company and address are as below; Board Director General Manager, LSI Design & Development Group Hitachi ULSI Systems Co., Ltd. 5-22-1 Josuihon-cho, Kodaira-shi, Tokyo 187-8522 Japan Phone Number and E-mail address were changed. Best regards, Hideki Fukuda ------------------------------------------------ Hideki Fukuda Hitachi ULSI Systems Co., Ltd. Tel +81-42-326-1111 Fax +81-42-328-1462 E-mail fukuda@hitachi-ul.co.jp ------------------------------------------------- -------- End of Forwarded Message From owner-ibis Thu May 14 08:04:39 1998 Received: from relayhost.vlsi.com (relayhost.vlsi.com [134.27.20.23]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id IAA16852 for ; Thu, 14 May 1998 08:04:38 -0700 (PDT) Received: (from nobody@localhost) by relayhost.vlsi.com (8.6.12/Hub-Perlotto/050895) id IAA29424; Thu, 14 May 1998 08:00:52 -0700 Received: from unknown(134.27.128.26) by osiris via smap (V2.0) id xma029414; Thu, 14 May 98 08:00:29 -0700 Received: from vlsi.com (witsend.tempe.vlsi.com [134.27.133.12]) by tem-pbx1.tempe.vlsi.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id HGKMTSQ7; Thu, 14 May 1998 07:59:41 -0700 Sender: dsession@vlsi.com Message-ID: <355B06A6.12AA373B@vlsi.com> Date: Thu, 14 May 1998 07:58:46 -0700 From: "D. C. Sessions" Reply-To: SI-List , IBIS Mailing list Organization: VLSI Technology Inc. X-Mailer: Mozilla 4.05 [en] (X11; U; SunOS 5.5.1 sun4m) MIME-Version: 1.0 To: IBIS Mailing list , SI-List Subject: Re: [SI-LIST] : Does IBIS describe output transition which both MOS turned on? References: <3559B0FD.47C81480@vlsi.com> <3559D300.784F@apsimtech.com> <355A1AF3.8FD2C1DA@vlsi.com> <355A35EB.181E@apsimtech.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Fred Balistreri wrote: > D. C. Sessions wrote: [snipperoo] > > Without going into the other uses of the v/t curves, they *can* be used > > to answer the present question, PROVIDED that the test load is heavy > > enough to be meaningful (A 10Kohm load isn't going to tell us much > > about the characteristics of a driver with an Rdson of twelve ohms.) > > The reason that this is so straightforward is that the crowbar > > current only flows for a brief time when both devices are nearly OFF > > anyway, so they are in deep saturation and thus the drain currents > > are pretty much independent of voltage. > > > > > One problem I see is that the v/t information by itself does not contain > > > the current information. > > > > Sure they do, it's just Ohm's Law: Id = Vout/Rload [more snip] > Id is not crowbar. So you still have to go back to the I/V data and dig > it out as I already mentioned. Ummm... no. Because the devices are in deep saturation at crossover, the v/i curve is pretty flat. All you really need is min( Idp, Idn ); the crowbar is the lesser of the pullup and pulldown currents. [Remainder addressed separately by Chris R.] -- D. C. Sessions dc.sessions@tempe.vlsi.com From owner-ibis Tue May 19 14:49:52 1998 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id OAA00872 for ; Tue, 19 May 1998 14:49:51 -0700 (PDT) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id PAA09720; Tue, 19 May 1998 15:01:31 -0700 (PDT) Received: from xtg801 (xtg801.pdx.intel.com [134.134.120.169]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id OAA18201; Tue, 19 May 1998 14:46:25 -0700 (PDT) Received: from ichips.intel.com by xtg801 (8.8.8/WW2.1 (Jones Farm)) id OAA27619; Tue, 19 May 1998 14:46:24 -0700 (PDT) Message-Id: <199805192146.OAA27619@xtg801> X-Mailer: exmh version 2.0delta 6/3/97 To: Ravinder Ajmani cc: si-list@silab.Eng.Sun.COM, ibis@eda.org Subject: Re: [SI-LIST] : IBIS Version 3.0 In-reply-to: Your message of "Tue, 19 May 1998 16:09:59 EDT." <5030100020678053000002L032*@MHS> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 19 May 1998 14:46:23 -0700 From: Stephen Peters Recently, Ravinder Ajmani wrote: > I have been approached by one of our chip vendors who wants to know if we would > require IBIS ver. 3.0 models. I will appreciate if someone can advise me about > the enhancements and benefits of using IBIS ver. 3.0 over ver. 2.1. > > Regards, > Ravinder Ajmani The major IBIS ver. 3.0 enhancements include: 1. Enhanced package model -- the ability to describe the package leads as uncoupled transmission lines and not just lumped L/R/C 2. The ability to explicitly describe an output that contains multiple output transistors with staggered turn-on/turn-off 3. The inclusion of data that allows for modeling of diode transit time effects. 4. The selection of alternate drivers on a signal 5. A new Electrical Board Description (.ebd file) that allows one to describe a SIMM or chip-on-board type module as one component. In brief, if your modeling SIMM modules, want better package models, or have a complex output that cannot be satisfactorily modeled using the existing V/T curves then including ver 3.0 data in your IBIS model may be required. I hope this helps. Best Regards, Stephen Peters Intel Corp. From owner-ibis Tue May 19 18:04:55 1998 Received: from relay1.UU.NET (relay1.UU.NET [192.48.96.5]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id SAA04059 for ; Tue, 19 May 1998 18:04:54 -0700 (PDT) Received: from uucp2.uu.net by relay1.UU.NET with SMTP (peer crosschecked as: uucp2.uu.net [192.48.96.82]) id QQeqcq11087; Tue, 19 May 1998 21:01:36 -0400 (EDT) Received: from qdt.UUCP by uucp2.uu.net with UUCP/RMAIL ; Tue, 19 May 1998 21:01:36 -0400 Received: from viewlogic.com by qdt.viewlogic.com (4.1/SMI-4.1) id AA14741; Tue, 19 May 98 18:03:05 PDT Received: from f14 by qdt.com (4.1/SMI-4.1) id AA26167; Tue, 19 May 98 18:02:12 PDT Sender: crokusek@qdt.com Message-Id: <35622A2F.500F9F30@viewlogic.com> Date: Tue, 19 May 1998 17:56:15 -0700 From: Chris Rokusek Organization: Viewlogic Systems X-Mailer: Mozilla 3.01 (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: ibis@eda.org Subject: Can't do T-LINE? Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit ( I am reposting this question in hopes of a more helpful response ) Hi All, Concerning [Path Description] section in Ver 3.x of .ibs... The 'len' parameter is given in 'units' which is 'arbitrary' (i.e. not meters) such that a distributed T-LINE model cannot be built with the proper physical length. ** I DO NOT WANT TO BUILD A LUMPED MODEL, I WANT TO BUILD A T-LINE MODEL ** Is this an oversight or am I not understanding the parameters? Best Regards, Chris Rokusek Viewlogic Systems |============================================================================= | Keyword: [Path Description] | Required: Yes | Description: This keyword allows the user to describe the connection | between the user accessible pins of a part and the pins of the | ICs mounted on that part. Each pin to node connection is | divided into one or more cascaded "sections", where each | section is described in terms of it's L/R/C per unit length. | The Fork and Endfork subparameters allow the path to branch to | multiple nodes, or another pin. A path description is | required for each pin whose signal name is not "GND", "POWER" | or "NC". | | Board Description and IC Boundaries: | | In any system, each part interfaces with another part at some | boundary. Every part model must contain the components | necessary to represent the behavior of the part being modeled | within its boundaries. The boundary definition depends upon | the parts being represented by the model. | | For CARD EDGE CONNECTIONS such as a SIMM or a PC Daughter | Card plugged into a SIMM Socket or Edge Connector, the | boundary should be at the end of the board card edge pads as | they emerge from the connector. | | For any THROUGH-HOLE MOUNTED PART, the boundary will be at the | surface of the board on which the part is mounted. | | SURFACE MOUNTED PART models end at the outboard end of their | recommended surface mount pads. | | If the board level component contains an UNMATED CONNECTOR, | the unmated connector will be described in a separate file, | with its boundaries being as described above for the | through-hole or surface mounted part. | | Sub-Params: Len, L, R, C, Fork, Endfork, Pin, Node | Usage Rules: Each individual connection path (user pin to node(s)) | description begins with the [Path Description] keyword and a | path name, followed by the subparameters used to describe the | path topology and the electrical characteristics of each | section of the path. The path name must not exceed 40 | characters, blanks are not allowed, and each occurrence of the | [Path Description] keyword must be followed by a unique path | name. Every signal pin (pins other than POWER, GND or NC) | must appear in one and only one path description per [Begin | Board Description]/[End Board Description] pair. Pin names do | not have to appear in the same order as listed in the [Pin | List] table. The individual subparameters are broken up into | those that describe the electrical properties of a section, | and those that describe the topology of a path. | | Section Description Subparameters: | | The Len, L, R, and C subparameters specify the length, the | series inductance and resistance and the capacitance to ground | of each section in a path description. | | Len The physical length of a section. Lengths are given | in terms of arbitrary 'units'. Any non-zero length | requires that the parameters that follow must be | interpreted as distributed elements by the simulator. | L The series inductance of a section, in terms of | 'inductance/unit length'. For example, if the total | inductance of a section is 3.0 nH and the length of | the section is 2 'units', the inductance would be | listed as L = 1.5 nH (i.e. 3.0 / 2). | C The capacitance to ground of a section, in terms of | capacitance per unit length. | R The series DC (ohmic) resistance of a section, in | terms of ohms per unit length. | | Topology Description Subparameters: | | The Fork and Endfork subparameters denote branches from the | main pin-to-node or pin-to-pin connection path. The Node | subparameter is used to reference the pin of a component or | board as defined in a .ibs or .ebd file. The Pin subparameter | is used to indicate the point at which a path connects to a | user visible pin. | | Fork This subparameter indicates that the sections | following (up to the Endfork subparameter) are part | of a branch off of the main connection path. This | subparameter has no arguments. | Endfork This subparameter indicates the end point of a branch. | For every Fork subparameter there must be a | corresponding Endfork subparameter. As with the Fork | subparameter, the Endfork subparameter has no | arguments. | Node reference_designator.pin | This subparameter is used when the connection path | connects to a pin of another, externally defined part. | The arguments of the Node subparameter indicate the | pin and reference designator of the external | component. The pin and reference designator portions | of the argument are separated by a period ("."). The | reference designator is mapped to an external | component description (another .ebd file or .ibs file) | by the [Reference Designator Map] Keyword. Note that | a Node MUST reference a model of a passive or active | component. A Node is not an arbitrary connection | point between two elements or paths. | Pin This subparameter is used to mark the point at which | a path description connects to a user accessible pin. | Every path description must contain at least one | occurrence of the Pin subparameter. It may also | contain the reserved word NC. The value of the Pin | subparameter must be one of the pin names listed in | the [Pin List] section. | | Using The Subparameters to Describe Paths: | | A section description begins with the Len subparameter and | ends with the slash (/) character. The value of the Len, L, | R, and C subparameters and the subparameter itself are | separated by an equals sign (=); whitespace around the equals | sign is optional. The Fork, Endfork, Node and Pin | subparameters are placed between section descriptions (i.e., | between the concluding slash of one section and the 'Len' | parameters that starts another). The arguments of the Pin and | Node subparameter are separated by white space. | | Specifying a Len or L/R/C value of zero is allowed. If | Len = 0 is specified, then the L/R/C values are the total for | that section. If a non-zero length is specified, then the | total L/R/C for a section is calculated by multiplying the | value of the Len subparameter by the value of the L, R, or C | subparameter. However, as noted below, if a non-zero length | is specified, that section MUST be interpreted as distributed | elements. | | Legal Subparameter Combinations for Section Descriptions: | | A) Len, and one or more of the L, R and C subparameters. If | the Len subparameter is given as zero, then the L/R/C | subparameters represent lumped elements. If the Len | subparameter is non-zero, then the L/R/C subparameters | represent distributed elements and both L and C must be | specified, R is optional. | | B) The first subparameter following the [Path Description] | keyword must be 'Pin', followed by one or more section | descriptions. The path description can terminate in a Node, | another pin or the reserved word, NC. | | Dealing With Series Elements: | | A discrete series R or L component can be included in a path | description by defining a section with L=0 and the proper R or | L value. A discrete series component can also be included in | a path description by writing two back to back node statements | that reference the same component (see the example below). | Note that both ends of a discrete, two terminal component MUST | be contained in a single [Path Description]. Connecting two | separate [Path Description] with a series component is not | allowed. |----------------------------------------------------------------------------- | | An Example Path For a SIMM Module: | [Path Description] CAS_2 Pin J25 Len = 0.5 L=8.35n C=3.34p R=0.01 / Node u21.15 Len = 0.5 L=8.35n C=3.34p R=0.01 / Node u22.15 Len = 0.5 L=8.35n C=3.34p R=0.01 / Node u23.15 | | A Description Using The Fork and Endfork Subparameters: | [Path Description] PassThru1 Pin B5 Len = 0 L=2.0n / Len = 2.1 L=6.0n C=2.0p / Fork Len = 1.0 L = 1.0n C= 2.0p / Node u23.15 Endfork Len = 1.0 L = 6.0n C=2.0p / Pin A5 | | A Description Including a Discrete Series Element: | [Path Description] sig1 Pin B27 Len = 0 L=1.6n / Len = 1.5 L=6.0n C=2.0p / Node R2.1 Node R2.2 Len = 0.25 L=6.0n C=2.0p / Node U25.6 | |============================================================================= From owner-ibis Tue May 19 19:09:14 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id TAA04896 for ; Tue, 19 May 1998 19:09:13 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id TAA19497; Tue, 19 May 1998 19:03:40 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id TAA17928; Tue, 19 May 1998 19:03:39 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA25049; Tue, 19 May 98 19:03:38 PDT Date: Tue, 19 May 98 19:03:38 PDT Message-Id: <9805200203.AA25049@bob> To: crokusek@viewlogic.com, ibis@eda.org Subject: Re: Can't do T-LINE? Cc: bobr@emicx.mentorg.com Chris: The L, C, and R parameters are given as CORRESPONDING per unit length values. These are multiplied by Len to produce the total distributed values for the exact length of T-line that you want. Whenever Len is not equal to zero, the section is interpreted as a distributed section (not a lumped section). The T-line relationships still hold: Zo = sqrt(L/C) TD = Len * sqrt(LC) So the electrical information is available for a T-line of whatever length you want. Best Regards, Bob Ross Interconnectix/Mentor Graphics > Sender: crokusek@qdt.com > Date: Tue, 19 May 1998 17:56:15 -0700 > From: Chris Rokusek > To: ibis@eda.org > Subject: Can't do T-LINE? > ( I am reposting this question in hopes of a more helpful response ) > Hi All, > Concerning [Path Description] section in Ver 3.x of .ibs... > The 'len' parameter is given in 'units' which is 'arbitrary' (i.e. not > meters) such that a distributed T-LINE model cannot be built with the > proper physical length. > ** I DO NOT WANT TO BUILD A LUMPED MODEL, I WANT TO BUILD A T-LINE MODEL > ** > Is this an oversight or am I not understanding the parameters? > Best Regards, > Chris Rokusek > Viewlogic Systems > > > |============================================================================= > | Keyword: [Path Description] > | Required: Yes > | Description: This keyword allows the user to describe the connection > | between the user accessible pins of a part and the pins > of the > | ICs mounted on that part. Each pin to node connection > is > | divided into one or more cascaded "sections", where each > | section is described in terms of it's L/R/C per unit > length. > | The Fork and Endfork subparameters allow the path to > branch to > | multiple nodes, or another pin. A path description is > | required for each pin whose signal name is not "GND", > "POWER" > | or "NC". > | > | Board Description and IC Boundaries: > | > | In any system, each part interfaces with another part at > some > | boundary. Every part model must contain the components > | necessary to represent the behavior of the part being > modeled > | within its boundaries. The boundary definition depends > upon > | the parts being represented by the model. > | > | For CARD EDGE CONNECTIONS such as a SIMM or a PC > Daughter > | Card plugged into a SIMM Socket or Edge Connector, the > | boundary should be at the end of the board card edge > pads as > | they emerge from the connector. > | > | For any THROUGH-HOLE MOUNTED PART, the boundary will be > at the > | surface of the board on which the part is mounted. > | > | SURFACE MOUNTED PART models end at the outboard end of > their > | recommended surface mount pads. > | > | If the board level component contains an UNMATED > CONNECTOR, > | the unmated connector will be described in a separate > file, > | with its boundaries being as described above for the > | through-hole or surface mounted part. > | > | Sub-Params: Len, L, R, C, Fork, Endfork, Pin, Node > | Usage Rules: Each individual connection path (user pin to node(s)) > | description begins with the [Path Description] keyword > and a > | path name, followed by the subparameters used to > describe the > | path topology and the electrical characteristics of each > | section of the path. The path name must not exceed 40 > | characters, blanks are not allowed, and each occurrence > of the > | [Path Description] keyword must be followed by a unique > path > | name. Every signal pin (pins other than POWER, GND or > NC) > | must appear in one and only one path description per > [Begin > | Board Description]/[End Board Description] pair. Pin > names do > | not have to appear in the same order as listed in the > [Pin > | List] table. The individual subparameters are broken up > into > | those that describe the electrical properties of a > section, > | and those that describe the topology of a path. > | > | Section Description Subparameters: > | > | The Len, L, R, and C subparameters specify the length, > the > | series inductance and resistance and the capacitance to > ground > | of each section in a path description. > | > | Len The physical length of a section. Lengths are > given > | in terms of arbitrary 'units'. Any non-zero > length > | requires that the parameters that follow must be > | interpreted as distributed elements by the > simulator. > | L The series inductance of a section, in terms of > | 'inductance/unit length'. For example, if the > total > | inductance of a section is 3.0 nH and the length > of > | the section is 2 'units', the inductance would > be > | listed as L = 1.5 nH (i.e. 3.0 / 2). > | C The capacitance to ground of a section, in terms > of > | capacitance per unit length. > | R The series DC (ohmic) resistance of a section, > in > | terms of ohms per unit length. > | > | Topology Description Subparameters: > | > | The Fork and Endfork subparameters denote branches from > the > | main pin-to-node or pin-to-pin connection path. The > Node > | subparameter is used to reference the pin of a component > or > | board as defined in a .ibs or .ebd file. The Pin > subparameter > | is used to indicate the point at which a path connects > to a > | user visible pin. > | > | Fork This subparameter indicates that the sections > | following (up to the Endfork subparameter) are > part > | of a branch off of the main connection path. > This > | subparameter has no arguments. > | Endfork This subparameter indicates the end point of a > branch. > | For every Fork subparameter there must be a > | corresponding Endfork subparameter. As with the > Fork > | subparameter, the Endfork subparameter has no > | arguments. > | Node reference_designator.pin > | This subparameter is used when the connection > path > | connects to a pin of another, externally defined > part. > | The arguments of the Node subparameter indicate > the > | pin and reference designator of the external > | component. The pin and reference designator > portions > | of the argument are separated by a period > ("."). The > | reference designator is mapped to an external > | component description (another .ebd file or .ibs > file) > | by the [Reference Designator Map] Keyword. Note > that > | a Node MUST reference a model of a passive or > active > | component. A Node is not an arbitrary > connection > | point between two elements or paths. > | Pin This subparameter is used to mark the point at > which > | a path description connects to a user accessible > pin. > | Every path description must contain at least one > | occurrence of the Pin subparameter. It may also > | contain the reserved word NC. The value of the > Pin > | subparameter must be one of the pin names listed > in > | the [Pin List] section. > | > | Using The Subparameters to Describe Paths: > | > | A section description begins with the Len subparameter > and > | ends with the slash (/) character. The value of the > Len, L, > | R, and C subparameters and the subparameter itself are > | separated by an equals sign (=); whitespace around the > equals > | sign is optional. The Fork, Endfork, Node and Pin > | subparameters are placed between section descriptions > (i.e., > | between the concluding slash of one section and the > 'Len' > | parameters that starts another). The arguments of the > Pin and > | Node subparameter are separated by white space. > | > | Specifying a Len or L/R/C value of zero is allowed. If > | Len = 0 is specified, then the L/R/C values are the > total for > | that section. If a non-zero length is specified, then > the > | total L/R/C for a section is calculated by multiplying > the > | value of the Len subparameter by the value of the L, R, > or C > | subparameter. However, as noted below, if a non-zero > length > | is specified, that section MUST be interpreted as > distributed > | elements. > | > | Legal Subparameter Combinations for Section > Descriptions: > | > | A) Len, and one or more of the L, R and C > subparameters. If > | the Len subparameter is given as zero, then the L/R/C > | subparameters represent lumped elements. If the Len > | subparameter is non-zero, then the L/R/C subparameters > | represent distributed elements and both L and C must be > | specified, R is optional. > | > | B) The first subparameter following the [Path > Description] > | keyword must be 'Pin', followed by one or more section > | descriptions. The path description can terminate in a > Node, > | another pin or the reserved word, NC. > | > | Dealing With Series Elements: > | > | A discrete series R or L component can be included in a > path > | description by defining a section with L=0 and the > proper R or > | L value. A discrete series component can also be > included in > | a path description by writing two back to back node > statements > | that reference the same component (see the example > below). > | Note that both ends of a discrete, two terminal > component MUST > | be contained in a single [Path Description]. Connecting > two > | separate [Path Description] with a series component is > not > | allowed. > |----------------------------------------------------------------------------- > | > | An Example Path For a SIMM Module: > | > [Path Description] CAS_2 > Pin J25 > Len = 0.5 L=8.35n C=3.34p R=0.01 / > Node u21.15 > Len = 0.5 L=8.35n C=3.34p R=0.01 / > Node u22.15 > Len = 0.5 L=8.35n C=3.34p R=0.01 / > Node u23.15 > | > | A Description Using The Fork and Endfork Subparameters: > | > [Path Description] PassThru1 > Pin B5 > Len = 0 L=2.0n / > Len = 2.1 L=6.0n C=2.0p / > Fork > Len = 1.0 L = 1.0n C= 2.0p / > Node u23.15 > Endfork > Len = 1.0 L = 6.0n C=2.0p / > Pin A5 > | > | A Description Including a Discrete Series Element: > | > [Path Description] sig1 > Pin B27 > Len = 0 L=1.6n / > Len = 1.5 L=6.0n C=2.0p / > Node R2.1 > Node R2.2 > Len = 0.25 L=6.0n C=2.0p / > Node U25.6 > | > |============================================================================= From owner-ibis Tue May 19 16:54:42 1998 Received: from relay5.UU.NET (relay5.UU.NET [192.48.96.15]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id QAA03021; Tue, 19 May 1998 16:54:41 -0700 (PDT) Received: from uucp2.uu.net by relay5.UU.NET with SMTP (peer crosschecked as: uucp2.uu.net [192.48.96.82]) id QQeqcl03627; Tue, 19 May 1998 19:51:21 -0400 (EDT) Received: from qdt.UUCP by uucp2.uu.net with UUCP/RMAIL ; Tue, 19 May 1998 19:51:23 -0400 Received: from viewlogic.com by qdt.viewlogic.com (4.1/SMI-4.1) id AA14360; Tue, 19 May 98 16:53:05 PDT Received: from f14 by qdt.com (4.1/SMI-4.1) id AA25635; Tue, 19 May 98 16:51:28 PDT Sender: crokusek@qdt.com Message-Id: <3562199B.13728473@viewlogic.com> Date: Tue, 19 May 1998 16:45:31 -0700 From: Chris Rokusek Organization: Viewlogic Systems X-Mailer: Mozilla 3.01 (X11; I; SunOS 4.1.4 sun4m) Mime-Version: 1.0 To: ibis@eda.org, ibis-users@eda.org Subject: Call for V3.0 Models References: <9805020022.AA12632@bob> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hi All, I would like to request any models with V3.0 features to test against the checker and our translator. An NDA agreement is not a problem if it is neccessary. If you have V3.0 models but are unable to give them out I am still interested in the knowing which features you are using from V3.0. If others are interested in obtaining V3.0 models please respond to me or post to the list and I can add your name to a distribution list (assuming I actually get some replies from this email). Best Regards, Chris Rokusek Viewlogic Systems (805) 988-8250 (805) 988-8259 fax From owner-ibis Tue May 19 20:42:41 1998 Received: from mail.nwlink.com (mail.nwlink.com [209.20.130.40]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id UAA06176 for ; Tue, 19 May 1998 20:42:40 -0700 (PDT) Received: from stargate (mail.hyperlynx.com [209.20.148.70]) by mail.nwlink.com (8.8.8/8.8.8) with SMTP id UAA23261; Tue, 19 May 1998 20:37:58 -0700 (PDT) Message-Id: <3.0.32.19980519204000.0098c940@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Tue, 19 May 1998 20:40:02 -0700 To: Chris Rokusek , ibis@eda.org From: Kellee Crisafulli Subject: Re: Can't do T-LINE? Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi Chris, This is not an oversight and you can and should build a distributed model if both L and C are present and it has non-zero length it is suppose to be a distributed model. Z0 = sqrt(L/C) delay = sqrt(L*C) The key is that the L and C are per unit length. as is stated in the text. Just multiply the delay times the length specified. At 05:56 PM 5/19/98 -0700, Chris Rokusek wrote: >( I am reposting this question in hopes of a more helpful response ) >Hi All, >Concerning [Path Description] section in Ver 3.x of .ibs... >The 'len' parameter is given in 'units' which is 'arbitrary' (i.e. not >meters) such that a distributed T-LINE model cannot be built with the >proper physical length. > >** I DO NOT WANT TO BUILD A LUMPED MODEL, I WANT TO BUILD A T-LINE MODEL >** > >Is this an oversight or am I not understanding the parameters? > >Best Regards, > >Chris Rokusek >Viewlogic Systems > > > >|========================================================================== === >| Keyword: [Path Description] >| Required: Yes >| Description: This keyword allows the user to describe the connection >| between the user accessible pins of a part and the pins >of the >| ICs mounted on that part. Each pin to node connection >is >| divided into one or more cascaded "sections", where each >| section is described in terms of it's L/R/C per unit >length. >| The Fork and Endfork subparameters allow the path to >branch to >| multiple nodes, or another pin. A path description is >| required for each pin whose signal name is not "GND", >"POWER" >| or "NC". >| >| Board Description and IC Boundaries: >| >| In any system, each part interfaces with another part at >some >| boundary. Every part model must contain the components >| necessary to represent the behavior of the part being >modeled >| within its boundaries. The boundary definition depends >upon >| the parts being represented by the model. >| >| For CARD EDGE CONNECTIONS such as a SIMM or a PC >Daughter >| Card plugged into a SIMM Socket or Edge Connector, the >| boundary should be at the end of the board card edge >pads as >| they emerge from the connector. >| >| For any THROUGH-HOLE MOUNTED PART, the boundary will be >at the >| surface of the board on which the part is mounted. >| >| SURFACE MOUNTED PART models end at the outboard end of >their >| recommended surface mount pads. >| >| If the board level component contains an UNMATED >CONNECTOR, >| the unmated connector will be described in a separate >file, >| with its boundaries being as described above for the >| through-hole or surface mounted part. >| >| Sub-Params: Len, L, R, C, Fork, Endfork, Pin, Node >| Usage Rules: Each individual connection path (user pin to node(s)) >| description begins with the [Path Description] keyword >and a >| path name, followed by the subparameters used to >describe the >| path topology and the electrical characteristics of each >| section of the path. The path name must not exceed 40 >| characters, blanks are not allowed, and each occurrence >of the >| [Path Description] keyword must be followed by a unique >path >| name. Every signal pin (pins other than POWER, GND or >NC) >| must appear in one and only one path description per >[Begin >| Board Description]/[End Board Description] pair. Pin >names do >| not have to appear in the same order as listed in the >[Pin >| List] table. The individual subparameters are broken up >into >| those that describe the electrical properties of a >section, >| and those that describe the topology of a path. >| >| Section Description Subparameters: >| >| The Len, L, R, and C subparameters specify the length, >the >| series inductance and resistance and the capacitance to >ground >| of each section in a path description. >| >| Len The physical length of a section. Lengths are >given >| in terms of arbitrary 'units'. Any non-zero >length >| requires that the parameters that follow must be >| interpreted as distributed elements by the >simulator. >| L The series inductance of a section, in terms of >| 'inductance/unit length'. For example, if the >total >| inductance of a section is 3.0 nH and the length >of >| the section is 2 'units', the inductance would >be >| listed as L = 1.5 nH (i.e. 3.0 / 2). >| C The capacitance to ground of a section, in terms >of >| capacitance per unit length. >| R The series DC (ohmic) resistance of a section, >in >| terms of ohms per unit length. >| >| Topology Description Subparameters: >| >| The Fork and Endfork subparameters denote branches from >the >| main pin-to-node or pin-to-pin connection path. The >Node >| subparameter is used to reference the pin of a component >or >| board as defined in a .ibs or .ebd file. The Pin >subparameter >| is used to indicate the point at which a path connects >to a >| user visible pin. >| >| Fork This subparameter indicates that the sections >| following (up to the Endfork subparameter) are >part >| of a branch off of the main connection path. >This >| subparameter has no arguments. >| Endfork This subparameter indicates the end point of a >branch. >| For every Fork subparameter there must be a >| corresponding Endfork subparameter. As with the >Fork >| subparameter, the Endfork subparameter has no >| arguments. >| Node reference_designator.pin >| This subparameter is used when the connection >path >| connects to a pin of another, externally defined >part. >| The arguments of the Node subparameter indicate >the >| pin and reference designator of the external >| component. The pin and reference designator >portions >| of the argument are separated by a period >("."). The >| reference designator is mapped to an external >| component description (another .ebd file or .ibs >file) >| by the [Reference Designator Map] Keyword. Note >that >| a Node MUST reference a model of a passive or >active >| component. A Node is not an arbitrary >connection >| point between two elements or paths. >| Pin This subparameter is used to mark the point at >which >| a path description connects to a user accessible >pin. >| Every path description must contain at least one >| occurrence of the Pin subparameter. It may also >| contain the reserved word NC. The value of the >Pin >| subparameter must be one of the pin names listed >in >| the [Pin List] section. >| >| Using The Subparameters to Describe Paths: >| >| A section description begins with the Len subparameter >and >| ends with the slash (/) character. The value of the >Len, L, >| R, and C subparameters and the subparameter itself are >| separated by an equals sign (=); whitespace around the >equals >| sign is optional. The Fork, Endfork, Node and Pin >| subparameters are placed between section descriptions >(i.e., >| between the concluding slash of one section and the >'Len' >| parameters that starts another). The arguments of the >Pin and >| Node subparameter are separated by white space. >| >| Specifying a Len or L/R/C value of zero is allowed. If >| Len = 0 is specified, then the L/R/C values are the >total for >| that section. If a non-zero length is specified, then >the >| total L/R/C for a section is calculated by multiplying >the >| value of the Len subparameter by the value of the L, R, >or C >| subparameter. However, as noted below, if a non-zero >length >| is specified, that section MUST be interpreted as >distributed >| elements. >| >| Legal Subparameter Combinations for Section >Descriptions: >| >| A) Len, and one or more of the L, R and C >subparameters. If >| the Len subparameter is given as zero, then the L/R/C >| subparameters represent lumped elements. If the Len >| subparameter is non-zero, then the L/R/C subparameters >| represent distributed elements and both L and C must be >| specified, R is optional. >| >| B) The first subparameter following the [Path >Description] >| keyword must be 'Pin', followed by one or more section >| descriptions. The path description can terminate in a >Node, >| another pin or the reserved word, NC. >| >| Dealing With Series Elements: >| >| A discrete series R or L component can be included in a >path >| description by defining a section with L=0 and the >proper R or >| L value. A discrete series component can also be >included in >| a path description by writing two back to back node >statements >| that reference the same component (see the example >below). >| Note that both ends of a discrete, two terminal >component MUST >| be contained in a single [Path Description]. Connecting >two >| separate [Path Description] with a series component is >not >| allowed. >|-------------------------------------------------------------------------- --- >| >| An Example Path For a SIMM Module: >| >[Path Description] CAS_2 >Pin J25 >Len = 0.5 L=8.35n C=3.34p R=0.01 / >Node u21.15 >Len = 0.5 L=8.35n C=3.34p R=0.01 / >Node u22.15 >Len = 0.5 L=8.35n C=3.34p R=0.01 / >Node u23.15 >| >| A Description Using The Fork and Endfork Subparameters: >| >[Path Description] PassThru1 >Pin B5 >Len = 0 L=2.0n / >Len = 2.1 L=6.0n C=2.0p / > Fork > Len = 1.0 L = 1.0n C= 2.0p / > Node u23.15 > Endfork >Len = 1.0 L = 6.0n C=2.0p / >Pin A5 >| >| A Description Including a Discrete Series Element: >| >[Path Description] sig1 >Pin B27 >Len = 0 L=1.6n / >Len = 1.5 L=6.0n C=2.0p / >Node R2.1 >Node R2.2 >Len = 0.25 L=6.0n C=2.0p / >Node U25.6 >| >|========================================================================== === > > From owner-ibis Wed May 20 00:26:24 1998 Received: from alcatel.fr (ns.rfs.tm.fr [194.133.58.131]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id AAA09490 for ; Wed, 20 May 1998 00:26:22 -0700 (PDT) Received: from alcatel.fr (gatekeeper-ssn.alcatel.fr [155.132.180.244]) by mailgate.alcatel.fr (ALCANET/SMTP.9.9.9) with ESMTP id JAA17538 for ; Wed, 20 May 1998 09:27:53 +0200 Received: from aifhs1.alcatel.fr (aifhs1.alcatel.fr [155.132.180.86]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id JAA05571; Wed, 20 May 1998 09:17:51 +0200 (MET DST) Received: from aifhs2.alcatel.fr (localhost [127.0.0.1]) by aifhs1.alcatel.fr (8.8.8/8.8.8) with ESMTP id JAA10837; Wed, 20 May 1998 09:21:41 +0200 (MET DST) Received: from las40304.ln.cit.alcatel.fr.ln.cit.alcatel.fr (las40304.ln.cit.alcatel.fr [155.132.225.2]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with SMTP id JAA05517; Wed, 20 May 1998 09:17:47 +0200 (MET DST) Received: from las41247.ln.cit.alcatel.fr by las40304.ln.cit.alcatel.fr.ln.cit.alcatel.fr (4.1/SMI-4.1) id AA09805; Wed, 20 May 98 09:26:31 +0200 Received: from las41247 (localhost) by las41247.ln.cit.alcatel.fr (4.1/SMI-4.1) id AA01035; Wed, 20 May 98 09:26:26 +0200 Sender: fitzpat1@ln.cit.alcatel.fr Message-Id: <356285A2.2781E494@ln.cit.alcatel.fr> Date: Wed, 20 May 1998 09:26:26 +0200 From: John V Fitzpatrick Organization: Alcatel Telecom, Lannion, France X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.3_U1 sun4m) Mime-Version: 1.0 To: ibis@eda.org Subject: Flight time measurements Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bonjour, Once upon a time, I proposed that IBIS 3.0 might allow input slewrates (V/ns or ns/V) be defined for a receiver: * SR1: "worst-case" slew-rate beyond which the receiver might oscillate * SR2: "best-case" slew-rate, the minimum for receiver timing to be valid. Having recently read the new GTL+ guidelines from Intel, available at http://developer.intel.com/design/Pentium/applnots/24373501.pdf, I think it's be worthwhile to fly this kite again... In paragraph 3.2 (pp 11-14) of the Intel document, the flight time calculation rules are: - if the input signal edge is faster than SR2 (0.3 V/ns), then flight-time is measured at Vref - if the input signal edge is slower than SR2, then flight time (for a rising edge) is obtained by extrapolating back to Vref, with a slope equal to SR2, from the crossing point with Vih. - if the signal is non-monotonic, then extrapolate back to Vref from the last Vih crossing point .... but with a different value of SR2 (0.8 V/ns). In my opinion, these are very sensible rules - even if I don't understand fully where 0.8 V/ns comes from. Unfortunately, IBIS does not allow SR2 to be specified. My questions: a) Do others on this list use these or similar rules? If so, what values do you use for SR2? b) Does the current generation of simulators allow for a SR2 parameter to be used in flight-time calculation? c) Would it be useful to add an entry under the [Model Spec] keyword to allow SR2 to be defined for a buffer? Regards, John -- John Fitzpatrick Alcatel Telecom, 4 rue de Broglie, 22304 Lannion, France Tel: +33(0)2.96.04.79.33 Fax: +33(0)2.96.04.85.09 From owner-ibis Wed May 20 01:52:27 1998 Received: from mail.nwlink.com (mail.nwlink.com [209.20.130.40]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id BAA10523 for ; Wed, 20 May 1998 01:52:26 -0700 (PDT) Received: from stargate (mail.hyperlynx.com [209.20.148.70]) by mail.nwlink.com (8.8.8/8.8.8) with SMTP id BAA09510; Wed, 20 May 1998 01:48:50 -0700 (PDT) Message-Id: <3.0.32.19980520015052.009437d0@mail.nwlink.com> X-Sender: kellee@mail.nwlink.com X-Mailer: Windows Eudora Pro Version 3.0 (32) Date: Wed, 20 May 1998 01:50:54 -0700 To: John V Fitzpatrick From: Kellee Crisafulli Subject: Re: Flight time measurements Cc: ibis@eda.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Hi John, I see logic in your argument. Did you actually write a bird last time? To make IBIS work everyone must participate. I hope you will consider submitting a BIRD (buffer issue resolution document). This is basically who,what,where,why, how with syntax. typically it would be a one page document. The BIRD outline is at the IBIS site. Actually if you submit the BIRD form it would start as an EGG than grow into a BIRD if you get no major objections. How about following the same syntax as the driver dv/dt just to be consistent. Best wishes Kellee At 09:26 AM 5/20/98 +0200, you wrote: >Bonjour, > >Once upon a time, I proposed that IBIS 3.0 might allow >input slewrates (V/ns or ns/V) be defined for a receiver: > * SR1: "worst-case" slew-rate beyond which the receiver > might oscillate > * SR2: "best-case" slew-rate, the minimum for receiver > timing to be valid. > >Having recently read the new GTL+ guidelines from Intel, available >at http://developer.intel.com/design/Pentium/applnots/24373501.pdf, >I think it's be worthwhile to fly this kite again... > >In paragraph 3.2 (pp 11-14) of the Intel document, the flight time >calculation rules are: > > - if the input signal edge is faster than SR2 (0.3 V/ns), > then flight-time is measured at Vref > - if the input signal edge is slower than SR2, > then flight time (for a rising edge) is obtained > by extrapolating back to Vref, with a slope equal to SR2, > from the crossing point with Vih. > - if the signal is non-monotonic, then extrapolate back to Vref > from the last Vih crossing point .... but with a different > value of SR2 (0.8 V/ns). > >In my opinion, these are very sensible rules - even if I don't >understand fully where 0.8 V/ns comes from. >Unfortunately, IBIS does not allow SR2 to be specified. > >My questions: > > a) Do others on this list use these or similar rules? > If so, what values do you use for SR2? > > b) Does the current generation of simulators allow for > a SR2 parameter to be used in flight-time calculation? > > c) Would it be useful to add an entry under the [Model Spec] > keyword to allow SR2 to be defined for a buffer? > >Regards, >John > >-- >John Fitzpatrick >Alcatel Telecom, 4 rue de Broglie, 22304 Lannion, France >Tel: +33(0)2.96.04.79.33 Fax: +33(0)2.96.04.85.09 > > From owner-ibis Wed May 20 03:32:35 1998 Received: from alcatel.fr (ns.celwave.tm.fr [194.133.58.131]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id DAA12491 for ; Wed, 20 May 1998 03:32:33 -0700 (PDT) Received: from alcatel.fr (gatekeeper-ssn.alcatel.fr [155.132.180.244]) by mailgate.alcatel.fr (ALCANET/SMTP.9.9.9) with ESMTP id MAA13133 for ; Wed, 20 May 1998 12:34:03 +0200 Received: from aifhs1.alcatel.fr (aifhs1.alcatel.fr [155.132.180.86]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id MAA24436 for ; Wed, 20 May 1998 12:24:01 +0200 (MET DST) Received: from aifhs2.alcatel.fr (localhost [127.0.0.1]) by aifhs1.alcatel.fr (8.8.8/8.8.8) with ESMTP id MAA18882 for ; Wed, 20 May 1998 12:27:53 +0200 (MET DST) Received: from las40304.ln.cit.alcatel.fr.ln.cit.alcatel.fr (las40304.ln.cit.alcatel.fr [155.132.225.2]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with SMTP id MAA24403 for ; Wed, 20 May 1998 12:23:57 +0200 (MET DST) Received: from las41247.ln.cit.alcatel.fr by las40304.ln.cit.alcatel.fr.ln.cit.alcatel.fr (4.1/SMI-4.1) id AA02481; Wed, 20 May 98 12:32:41 +0200 Received: from las41247 (localhost) by las41247.ln.cit.alcatel.fr (4.1/SMI-4.1) id AA01074; Wed, 20 May 98 12:32:18 +0200 Sender: fitzpat1@ln.cit.alcatel.fr Message-Id: <3562B131.446B9B3D@ln.cit.alcatel.fr> Date: Wed, 20 May 1998 12:32:17 +0200 From: John V Fitzpatrick Organization: Alcatel Telecom, Lannion, France X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.3_U1 sun4m) Mime-Version: 1.0 To: ibis@eda.org Subject: Ooops! [Fwd: Flight time measurements] Content-Type: multipart/mixed; boundary="------------794BDF3215FB748359E2B600" This is a multi-part message in MIME format. --------------794BDF3215FB748359E2B600 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Ooops, I made a typo: the Intel URL is : http://developer.intel.com/design/PentiumII/applnots/24373501.pdf A summary of the document is available at: http://developer.intel.com/design/PentiumII/applnots/243735.htm --------------794BDF3215FB748359E2B600 Content-Type: message/rfc822 Content-Transfer-Encoding: 7bit Content-Disposition: inline Received: from las40304 by lars0311.ln.cit.alcatel.fr (AIX 4.1/UCB 5.64/4.03) id AA30916; Wed, 20 May 1998 09:53:02 +0200 Received: from lars0311.ln.cit.alcatel.fr (lars0317.ln.cit.alcatel.fr) by las40304.ln.cit.alcatel.fr.ln.cit.alcatel.fr (4.1/SMI-4.1) id AA10109; Wed, 20 May 98 09:53:01 +0200 Received: from dnsln by lars0311.ln.cit.alcatel.fr (AIX 4.1/UCB 5.64/4.03) id AA28862; Wed, 20 May 1998 09:53:00 +0200 Received: from mail.nethq.alcatel.fr by dnsln.ln.cit.alcatel.fr (AIX 4.1/UCB 5.64/4.03) id AA07816; Wed, 20 May 1998 09:50:50 +0200 Received: from aifhs1.alcatel.fr (aifhs1.alcatel.fr [155.132.180.86]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id JAA17013; Wed, 20 May 1998 09:44:10 +0200 (MET DST) Received: from aifhs2.alcatel.fr (localhost [127.0.0.1]) by aifhs1.alcatel.fr (8.8.8/8.8.8) with ESMTP id JAA16369; Wed, 20 May 1998 09:48:01 +0200 (MET DST) Received: from mailgate.alcatel.fr (mailgate.alcatel.fr [155.132.180.242]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id JAA16980; Wed, 20 May 1998 09:44:06 +0200 (MET DST) Received: from server.vhdl.org (server.vhdl.org [198.31.14.3]) by mailgate.alcatel.fr (ALCANET/SMTP.9.9.9) with ESMTP id JAA21712; Wed, 20 May 1998 09:54:03 +0200 Received: from alcatel.fr (ns.rfs.tm.fr [194.133.58.131]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id AAA09490 for ; Wed, 20 May 1998 00:26:22 -0700 (PDT) Received: from alcatel.fr (gatekeeper-ssn.alcatel.fr [155.132.180.244]) by mailgate.alcatel.fr (ALCANET/SMTP.9.9.9) with ESMTP id JAA17538 for ; Wed, 20 May 1998 09:27:53 +0200 Received: from aifhs1.alcatel.fr (aifhs1.alcatel.fr [155.132.180.86]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with ESMTP id JAA05571; Wed, 20 May 1998 09:17:51 +0200 (MET DST) Received: from aifhs2.alcatel.fr (localhost [127.0.0.1]) by aifhs1.alcatel.fr (8.8.8/8.8.8) with ESMTP id JAA10837; Wed, 20 May 1998 09:21:41 +0200 (MET DST) Received: from las40304.ln.cit.alcatel.fr.ln.cit.alcatel.fr (las40304.ln.cit.alcatel.fr [155.132.225.2]) by aifhs2.alcatel.fr (ALCANET/SMTP2) with SMTP id JAA05517; Wed, 20 May 1998 09:17:47 +0200 (MET DST) Received: from las41247.ln.cit.alcatel.fr by las40304.ln.cit.alcatel.fr.ln.cit.alcatel.fr (4.1/SMI-4.1) id AA09805; Wed, 20 May 98 09:26:31 +0200 Received: from las41247 (localhost) by las41247.ln.cit.alcatel.fr (4.1/SMI-4.1) id AA01035; Wed, 20 May 98 09:26:26 +0200 Sender: fitzpat1@dnsln.ln.cit.alcatel.fr Message-Id: <356285A2.2781E494@ln.cit.alcatel.fr> Date: Wed, 20 May 1998 09:26:26 +0200 From: John V Fitzpatrick Organization: Alcatel Telecom, Lannion, France X-Mailer: Mozilla 3.01Gold (X11; I; SunOS 4.1.3_U1 sun4m) Mime-Version: 1.0 To: ibis@eda.org Subject: Flight time measurements Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Bonjour, Once upon a time, I proposed that IBIS 3.0 might allow input slewrates (V/ns or ns/V) be defined for a receiver: * SR1: "worst-case" slew-rate beyond which the receiver might oscillate * SR2: "best-case" slew-rate, the minimum for receiver timing to be valid. Having recently read the new GTL+ guidelines from Intel, available at http://developer.intel.com/design/Pentium/applnots/24373501.pdf, I think it's be worthwhile to fly this kite again... In paragraph 3.2 (pp 11-14) of the Intel document, the flight time calculation rules are: - if the input signal edge is faster than SR2 (0.3 V/ns), then flight-time is measured at Vref - if the input signal edge is slower than SR2, then flight time (for a rising edge) is obtained by extrapolating back to Vref, with a slope equal to SR2, from the crossing point with Vih. - if the signal is non-monotonic, then extrapolate back to Vref from the last Vih crossing point .... but with a different value of SR2 (0.8 V/ns). In my opinion, these are very sensible rules - even if I don't understand fully where 0.8 V/ns comes from. Unfortunately, IBIS does not allow SR2 to be specified. My questions: a) Do others on this list use these or similar rules? If so, what values do you use for SR2? b) Does the current generation of simulators allow for a SR2 parameter to be used in flight-time calculation? c) Would it be useful to add an entry under the [Model Spec] keyword to allow SR2 to be defined for a buffer? Regards, John -- John Fitzpatrick Alcatel Telecom, 4 rue de Broglie, 22304 Lannion, France Tel: +33(0)2.96.04.79.33 Fax: +33(0)2.96.04.85.09 --------------794BDF3215FB748359E2B600-- From owner-ibis Wed May 20 04:38:57 1998 Received: from mail13.digital.com (mail13.digital.com [192.208.46.30]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id EAA13505 for ; Wed, 20 May 1998 04:38:57 -0700 (PDT) Received: from sbuamazko2ae.zko.dec.com (sbuamazko2ae.zko.dec.com [16.29.160.92]) by mail13.digital.com (8.8.8/8.8.8/WV1.0e) with ESMTP id HAA29294 for ; Wed, 20 May 1998 07:35:11 -0400 (EDT) Received: by sbuamazko2ae.zko.dec.com with Internet Mail Service (5.0.1458.49) id ; Wed, 20 May 1998 07:35:29 -0400 Message-ID: <890ED1999E9CD01197A10000F84AA1F7A2EA7D@sbuamapko3cc.eng.pko.dec.com> From: Andrew Ingraham To: "'Chris Rokusek'" Cc: ibis@eda.org Subject: RE: Can't do T-LINE? Date: Wed, 20 May 1998 07:35:20 -0400 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain > The 'len' parameter is given in 'units' which is 'arbitrary' (i.e. not > meters) such that a distributed T-LINE model cannot be built with the > proper physical length. The 'len' parameter is in arbitrary 'units' which allows you to use meters, while someone else could use mm, inches, feet, or whatever ... as long as they are consistent with the rest of the t-line parameters, L/R/C. Regards, Andy From owner-ibis Wed May 20 09:06:25 1998 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id JAA18149 for ; Wed, 20 May 1998 09:06:24 -0700 (PDT) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id JAA00453 for ; Wed, 20 May 1998 09:15:33 -0700 (PDT) Received: from xtg801 (xtg801.pdx.intel.com [134.134.120.169]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id JAA19815 for ; Wed, 20 May 1998 09:03:06 -0700 (PDT) Received: from ichips.intel.com by xtg801 (8.8.8/WW2.1 (Jones Farm)) id JAA03396; Wed, 20 May 1998 09:03:05 -0700 (PDT) Message-Id: <199805201603.JAA03396@xtg801> X-Mailer: exmh version 2.0delta 6/3/97 To: ibis@eda.org Subject: IBIS Open Forum Meeting Minutes 5/19 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 May 1998 09:03:04 -0700 From: Stephen Peters DATE: 5/19/98 SUBJECT: 5/15/98 EIA IBIS Open Forum Minutes VOTING MEMBERS AND 1998 PARTICIPANTS LIST: AMP (Martin Freedman) Applied Simulation Technology Norio Matsui, Raj Raghuram* Cadence Design (& UniCAD) C. Kumar, Don Telian, Patrick Riffault, Craig Lewis, Greg Fitzgerald, Paul Galloway, Patrick Dos Santos, Catherine Weiss, Alain Tribaudot, Geoffrey Ellis Cypress (Bruce Wenniger) Digital Equipment Corp. Jeff Chu, Greg Edlund*, Bob Haller Hewlett Packard (EEsof, etc.) Karl Kachigan, Henry Wu, Paul Gregory High Design Technology Razvan Ene HyperLynx Kellee Crisafulli, Matthew Flora* Incases Olaf Rethmeier, Scott Jacobson, Werner Rissiek Intel Corporation Stephen Peters*, Arpad Muranyi*, Frank Kern, Will Hobbs, Prakash Radhakrishnan, Mohammed Hawana* Columbia, SC (formerly NCR) Dave Moxley* Mentor Graphics (Zeelan, Bob Ross*, George Opsahl, Mark Noneman, Interconnectix, etc.) Tom Dagostino, Karine Loudet, Jean Oudinot, Manuel De Almeida, Stephane Rousseau, Nevin Orhanovic Mitsubishi Hoang Nguyen, Tam Cao Motorola (Ron Werner) National Semiconductor Syed Huq, Cheng-Yang Kao, John Goldie, Ikchang Song North East Systems Associates Edward Sayre, Kathy Breda (NESA) NEC (Hiroshi Matsumoto) Quantic EMC (Mike Ventham) Texas Instruments Thomas Fisher, Harvey Stiegler, Vincent Chang, Jean-Claude Perrin*, Peter Forstner Thomson-CSF Jean-Marc Claveau, Laurent Duzaic, Saverio Lerose, Benoit Meyniel, Jean Lefebvre Viewlogic Jon Powell, Chris Rokusek, Guy de Burgh, Gary Mandel VeriBest Ian Dodd, David Weins, Ian Gabbitas VLSI Technology D.C. Sessions Zuken-Redac (John Berrie) OTHER PARTICIPANTS IN 1998: Actel Eric Tardif, Emmonvelle Gaudin Aerospatiale Lionel Dreux, Claude Huet Alcatel (Bell, Espace, etc.) John Fitzpatrick, W. Temmerman, Laure Bessettes, Jean-Claude Pourtau, Daniel Peron ALS Design Yves Mouquet Ansoft Eric Bogatin Apple Fred Floresca, Danny Itani Apteq Design Systems Dan FitzPatrick Avanti Nik Bannov CERN Olivier Clere, Jean-Michel Sainson, Rudi Zurbroken Compaq Shariq Rahma Crucial Technology Rathna Reddy EIA Patti Rusher* EMC Fawn Engelmann ENST, Paris Jean-Jacques Charlot European CAD Standardization Adam Morawiec Intitiative (ECSI) Fairchild Semiconductor Peter LaFlamme H.A.S Electronics Haruny Said Intracon Design Ltd. Derek Laidlaw Philips Semiconductor Todd Andersen* Scottish Electronics Robert Easson Manufacturing Center (SEMC) Seagate Vanessa Howard SGS-Thomson Philippe Lefevre Siemens Gerald Bannert, Bernhard Unger, Christian Marot, Miguel Hernandez, Gil Russell Symmetry Andy Hughes Tektronix Nassrin Ghahyasi Ultratest International Chris O'Connor Xilinx Susan Wu In the list above, attendees at the meeting are indicated by *. Principal members or other active members who have not attended are in parentheses. Participants who no longer are in the organization are in square brackets. Upcoming Meetings: The bridge numbers for future IBIS teleconferences are as follows: Date Bridge Number Reservation # Passcode June 5, 1998 (916) 356-9200 4-167410 9468535 June 18, 1998 IBIS Summit Meeting - No Phone Bridge All meetings are 8:00 AM to 9:55 AM Pacific Time. We try to have agendas out 7 days before each Open Forum and meeting minutes out within 7 days after. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the reservation number and passcode. NOTE: "AR" = Action Required. -------------------------------- MINUTES ------------------------------------- INTRODUCTIONS AND MEETING QUORUM Mohammed Hawana heads the XTG modeling group from Intel and is involved in distributing I/O Buffer Models. MEMBERSHIP UPDATE AND TREASURER'S REPORT Patti Rusher sent Bob Ross a financial report. Bob stated that there are 23 IBIS members. He is tracking down the payment status for one membership and for four parser invoices, and Patti is checking with the EIA accounting department regarding whether payment has been made. REVIEW OF MINUTES AND AR'S Bob noted that some minor editorial corrections were made on the April 24, minutes. The ARs will be discussed during the meeting. MISCELLANY/ANNOUNCEMENTS Syed Huq is out until Wednesday, May 27, 1998 to be home for his second baby. PRESS AND WEB PAGE UPDATES Greg Edlund stated that the May 1998 issue of Printed Circuit Design contains his article "IBIS Model Accuracy" on pages 40-42. Bob Ross mentioned a brief writeup on the Cadence free modeler in the April 23, 1998 issue of EDN, pg. 14. NEW MODELS AVAILABLE, LIBRARY UPDATE Jon Powell updated the official EIA IBIS home page Model links with many updates found by Matthew Flora and Bob Ross. Some of these are noted below: Atmel URL is changed to: http://www.atmel.com/atmel/products/prod180.htm Enhanced Memory Systems (owned by Ramptron International Corporation) has a model request form which includes IBIS Models: http://www.edram.com/modelfrm.html Fairchild Semiconductor no longer has CGS models, and the GTL URL has changed: http://www.fairchildsemi.com/models/ibis/gtl/index.html Hewlett-Packard has added an IBIS model for the Gigabyte products: http://hpcc920.external.hp.com/HP-COMP/gigabit/ibis.html IBM has added some Power-PC IBIS models at http://www.chips.ibm.com/products/ppc/documents/datasheets/products.html IC Works is has IBIS models at: http://www.icworks.com/IBIS Integrated Device Technology URL has changed to: http://www.idt.com/models/Welcome.html International Microelectronics, Inc. FTP site is relocated to: ftp://ftp13.ba.best.com/pub/imiweb8/ibis Mosel Vitelic has DRAM model for 16M and 64M devices at http://www.moselvitelic.com/sec2/Dynamic.html Motorola has added several links for IBIS models for Fast SRAM products. Select Asynchronous Fast SRAMs, Burst RAMs, Integrated Cache Solutions, and Tag RAMs under: http://www.mot.com/SPS/FastSRAM/productupdate The Samsung links have been changing. For a while they were supplying DRAM models, and the SRAM link had a listing of models and a request form at the bottom. However, it now appears that the top level link is needed. You select Products and the "Service" paths to get to the IBIS models. The SRAM IBIS model listing and request form are available. A DRAM path is not activated. The Graphics RAM IBIS models listed, but the IBIS links are not working. The top level link is: http://www.sec.samsung.com Texas Intruments has some PC100 sites for ALVC and CDC models: http://www.ti.com/sc/docs/asl/pc100.htm http://www.ti.com/sc/docs/msp/cdc/pc100.htm OPENS FOR NEW ISSUES Patti Rusher and Bob Ross on the EDA Booth and IBIS Meeting at the Design Automation Conference. INTERNATIONAL/EXTERNAL PROGRESS - IEC 62014-1 (IBIS Version 2.1) - Patti Rusher indicated that a meeting was held where a number of IEC numbers were changed. However, the IBIS number is still the same. Patti is still waiting for IEC 60214-1 to be formally ratified - possibly at the IEC meeting in September, 1998. - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuit (IMIC) - Bob Ross got a message from Fukuda-san regarding the web page below: http://tsc.eiaj.or.jp The "Outline of I/O Interface Project Group" link is new, and Version 1.1 dated March 31, 1998 is in a .pfd format. Bob noted that a few pages could not be printed because of some font problems. The comment deadline is June 10, 1998 - IEC 93/67/NP IBIS and EMC Simulation - Jean-Claude Perrin reported that another meeting will be held in May, 1998. Jean-Claude sent Bob Ross the Power Point presentation given at the February 27, 1998 Experts meeting in Paris, and Bob has uploaded it to eda.org under the /pub/ibis/wip directory. - JC-16B - Patti Rusher stated that she is reserving more hotel space at an adjacent hotel for the co-located JEDEC and IBIS Summit meeting to be held in San Diego in December, 1998. Patti indicated that while the scope of the JEDEC committee includes software, the committee itself is not really doing any work in this area. Bob Ross indicated interest in the flexible impedance driver work that D.C. Sessions mentioned in some recent signal integrity reflector discussions. IBIS EAST USERS GROUP ACTIVITIES Greg Edlund reported that the Model and Validation subcommittee will be meeting on Thursday, May 21, 1998 at Digital. He will get a telephone number for interested people to call in. The regular Users group meeting is moved to Thursday, May 28, 1998 and will be held at Stratus Computer. Greg contacted Kathy Breda, and the plan is to consider an IBIS course at or near the IBIS Summit location to be held in October, 1998. The class is not planned to be tied in with the PCB Conference East. IBIS LOGO CHANGE No vote was held. Rather, the committee decided to use the current logo that is on the EIA IBIS Home page. Some minor changes were suggested at the April 24, 1998 meeting regarding the IBIS name size, etc., but no alternative designs have been created. Patti Rusher mentioned that the logo will be refined and will be of a higher quality in preparation for the Design Automation Conference (DAC) EDA booth graphics displays . Bob indicated that changes could be made after DAC, but the logo already looks very good. At the April 24, 1998 meeting, the question was raised, but not addressed, on whether the IBIS Users group could use the new IBIS logo. Bob supported the IBIS Users Group using the IBIS logo, if they wish, since the work the Users Group is doing is in close cooperation with the IBIS Open Forum. EDITING COMMITTEE Bob Ross uploaded an UNOFFICIAL IBIS ver3_1c.ibs document with the BIRD47 change and other minor changes on eda.org under /pub/ibis/wip. The BNF AR remains. AR - Bob Ross generate and post a BNF for IBIS Version 3.0 (an IBIS Version 3.0 ratification AR). BIRD44 - INTERPRETATION OF MIN/MAX/WEAK/STRONG DATA Bob Ross indicated no progress. AR - Andy Ingraham to issue BIRD44.1 with the changes and extensions noted in the March 13, 1998 IBIS Open Forum meeting minutes. IBISCHK2+ (VER 2.1.15) PROGRESS Matthew Flora indicated that he received a set of changes from Chris Rokusek to make the parser work equally well in UNIX and DOS environments. Bob Ross indicated that there are currently six BUGs fixed in the ibischk3 and ebdchk3 preliminary code, and these fixes should be planned for the Version 2.1.16 release. BUG28 - ENDPOINT MISSED DUE TO FLOATING POINT PRECISION Bob Ross explained that Chris Rokusek discovered and provided a correction to a floating point precision problem when the load line intersection point falls exactly on a I/V segment endpoint. Chris' solution involves setting a tolerance limit for floating point compares. Bob classified this as Moderate, Medium, Open, and intends that this fix be rolled into ibischk2+ Version 2.1.16. VERSION 3.1 PARSER DEVELOPMENT Bob Ross stated that he did a review of the ibischk3 and ebdchk3 Version 3.0.1 and sent the comments to Atul Agarwal. Overall, the parsers are in very good shape and are very useful in their preliminary forms. Bob mentioned that there were a few error messages that were confusing or missing. Also he might want to change the warning messages for negative times under [Model Spec] to error messages. The test files for the Electrical Board Description are functioning. However, more test files and more investigation would be valuable. He encourages anyone interested in the .ebd syntax to look at that part of the parser. Chris Rokusek provide Bob the executables for the Version 3.0.1 release, and Bob uploaded them to eda.org under /pub/ibis/ibischk3 in a compressed form per the AR. These are preliminary code, but should be useful for review and for doing IBIS Version 3.0 extensions. COOKBOOK Stephen Peters reports that there no is progress on the Cookbook project. IBIS MODEL REVIEW COMMITTEE DISCUSSION Matthew Flora indicated no activity other than one model that he did not forward since it did not pass the ibischk2+ test. Matthew suggested that information about the IBIS Model Review committee and process be sent out again. Bob suggested that Matthew prepare a short writeup indicating that models for review should be sent to Matthew. They will be distributed to to five other EDA tool vendors for review. Comments and suggestions will be given back privately to the model developer. The purpose is to help the model developer provide better models and information that the EDA tools need to process IBIS models. Matthew indicated that the reference to the Model Review committee in Greg Edlund's article mentioned above may have left the false impression that only Hyperlynx will be reviewing the models. For general information, the contact person is: Matthew Flora, HyperLynx mbflora@hyperlynx.com AR - Matthew Flora issue to the IBIS reflector a short writeup on the IBIS IBIS Model Review committee. DESIGN AUTOMATION CONFERENCE (DAC) IBIS SUMMIT MEETING AND EDA BOOTH Patti Rusher had asked whether the IBIS committee wanted to have handouts for the EDA booth at DAC. After some discussion, the only handout will be a one page writeup on IBIS giving some general information and some sources for more information. Much information including magazine information and IBIS links are already on line. Bob Ross asked Stephen Peters to prepare a one-page handout. AR - Stephen Peters prepare a one page IBIS information sheet to be handed out at the EDA booth at DAC. Bob indicated that the agenda is open for the San Francisco IBIS Summit meeting at DAC on June 18, 1998. Election of officers will be held. Bob expects some technical discussions and presentations to relate to the BIRDs that are being considered. However, other presentations will be welcome. Bob will send out information on the DAC IBIS Summit meeting including a request for presentations. BIRD42.3 - MODELING CURRENT WAVEFORMS Bob Ross stated that there was some signal integrity and IBIS reflector discussion on crowbar currents that are related to this issue. Bob is planning that BIRD42.3 be discussed at the next (June 8, 1998) IBIS meeting. BIRD48.1 - ADD MODEL BIRD49.1 - ADD MODEL DYNAMIC CLAMPS BIRD50 - ADD MODEL BUS HOLD Bob Ross had sent out BIRD48.1 and BIRD49.1 and introduced the revisions. Bob mentioned that he and Arpad Muranyi also had discussed the extensions the previous day. One revision in BIRD48.1 was add additional references in the [Model] keyword for the Dynamic_clamp and Bus_hold subparameters of Model_type. Also, the Add_model_mode subparameter was added to the [Model] keyword sub- parameter list. It is to be used when the model is used as an added model. The Add_model_mode arguments are Output and Non-Output. When the top-level model is an I/O or 3-state model, the Add_model_mode is used to restrict the operation of the added model, if needed, to just Output mode or Input or 3-state mode. For example, the dynamic clamp functionality may exist only for the Input mode of an I/O buffer. Arpad suggested changing the names of the arguments to Driving and Non-driving, and Bob agreed. There was discussion concerning whether the Add_model_mode subparameter should be in the added model or in the top-level model which calls the added model. One advantage of moving it to the top level is that the modes of operation for the added model will clearly tie in with the Model_type of the top-level model. Stephen Peters questioned whether the [Driver Schedule] keyword is impacted by the Add Model structures, and Bob indicated that the Add Model details are separate. Bob also noted that the V_trig_r and V_trig_f syntax would be corrected to V_trigger_r and V_trigger_f, consistent with BIRD49.1 and BIRD50 usage. Some other text corrections will be made for notation and clarity per discussions at the meeting and with Arpad. BIRD49.1 extended the dynamic clamp functionality to include a non-triggered method of invoking it. In practice, dynamic clamps can also be invoked by a separate clock. The method proposed in BIRD49.1 involves using a negative time value as the first entry of the [GND Pulse Table] or [POWER Pulse Table] keyword. The corresponding V_trigger_f or V_trigger_r entries would be omitted or ignored. There was some discussion and concern on using negative numbers, and this will be investigated. Arpad had provided a several technical and editorial comments off line. Stephen Peters will also provide some editorial comments off line to be considered. BIRD50 remains unchanged regarding the bus hold functionality and was not reissued. However, the title is incorrect, so BIRD50.1 will be issued to at least change the title. Bob noted that the functionality can be used beyond just modeling bus hold. AR - Bob Ross issue BIRD48.2, BIRD49.2 and BIRD50.1 to capture the changes in this discussion and in the off line discussions. Bob Ross is planning to call for a vote BIRD48.2, BIRD49.2, and BIRD50.1 at the June 5, 1998 meeting. Stephen commented that he would like more participation by EDA vendors on this discussion. Bob agreed to discuss this with some of the EDA vendors. BIRD46.1 - RELAXATION OF SOME IBIS FILE NAME RESTRICTIONS Since BIRD46.1 has not been issued, Bob Ross deferred the discussion. AR - Matthew Flora issue BIRD46.1 to include references to the .pkg file and .ebd file and to change the limitation from 64 total characters to a limit of 20 characters and delete the references to allowing the period "." character. BIRD51 - 3-STATE ECL Bob Ross introduced BIRD51. Even though BIRD51 extends over several pages, it changes only a few lines to add 3-state-ECL to the list of Model_type subparameters under [Model] and under Ramp in Notes on Data Derivation section. As indicated before, several ECL devices with a true high-Z mode. BIRD51 will be scheduled for a vote at the next meeting. NEXT MEETING: The next teleconference meeting is on Friday, June 5, 1998, 8:00 A.M. to 9:55 A.M. BIRD48.2, BIRD49.2, BIRD50.1, BIRD51, will be scheduled for a vote. BIRD46.1, if issued, is scheduled for a vote. BIRD42.3 is scheduled for technical discussion. ============================================================================== NOTES IBIS CHAIR: Bob Ross (503) 685-0732, Fax (503) 685-4897 bob_ross@mentorg.com Modeling Engineer, Interconnectix BU of Mentor Graphics 8005 S.W. Boeckman Road, Wilsonville, OR 97070 VICE CHAIR: Syed Huq (408) 721-4874, Fax: (408) 721-4785 huq@rockie.nsc.com Staff Applications Engineer, National Semiconductor, M/S A-2595 2900 Semiconductor Drive, Santa Clara, CA 95052 SECRETARY: Stephen Peters (503) 264-4108, Fax: (503) 264-4515 sjpeters@ichips.intel.com Senior Hardware Engineer, Intel Corporation M/S JF1-56 2111 NE 25th Ave. Hillsboro, Oregon 97124-5961 LIBRARIAN: Jon Powell (805) 988-8250, Fax: (805) 988-8259 jonp@qdt.com Senior Scientist, Viewlogic (formerly Quad Design) 1385 Del Norte Rd., Camarillo, CA 93010 This meeting was conducted in accordance with the EIA Legal Guides and EIA Manual of Organization and Procedure. The following e-mail addresses are used: ibis-request@eda.org To join, change, or drop from either the IBIS Open Forum Reflector (ibis@eda.org), the IBIS Users' Group Reflector (ibis-users@eda.org) or both. State your request. ibis-info@eda.org To obtain general information about IBIS, to ask specific questions for individual response, and to inquire about joining the EIA-IBIS Open Forum as a full Member. ibis@eda.org To send a message to the general IBIS Open Forum Reflector. This is used mostly for IBIS Standardization business and future IBIS technical enhancements. Job posting information is not permitted. ibis-users@eda.org To send a message to the IBIS Users' Group Reflector. This is used mostly for IBIS clarification, current modeling issues, and general user concerns. Job posting information is not permitted. ibischk-bug@eda.org To report ibischk2 parser bugs. The Bug Report Form Resides on eda.org in /pub/ibis/bugs/ibischk/bugform.txt along with reported bugs. To report s2ibis, s2ibis2 and s2iplt bugs, use the Bug Report Forms which reside under eda.org in /pub/ibis/bugs/s2ibis/bugs2i.txt, /pub/ibis/bugs/s2ibis2/bugs2i2.txt, & /pub/ibis/bugs/s2iplt/bugsplt.txt respectively. Information on IBIS technical contents, IBIS participants, and actual IBIS models are available on the IBIS Home page found by selecting the Electronic Information Group under: http://www.eia.org Check the pub/ibis directory on eda.org for more information on previous discussions and results. You can get on via FTP anonymous. ============================================================================== From owner-ibis Wed May 20 16:22:50 1998 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id QAA25430; Wed, 20 May 1998 16:22:50 -0700 (PDT) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id QAA27899; Wed, 20 May 1998 16:30:58 -0700 (PDT) Received: from xtg801 (xtg801.pdx.intel.com [134.134.120.169]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id QAA12864; Wed, 20 May 1998 16:19:34 -0700 (PDT) Received: from ichips.intel.com by xtg801 (8.8.8/WW2.1 (Jones Farm)) id QAA05915; Wed, 20 May 1998 16:19:33 -0700 (PDT) Message-Id: <199805202319.QAA05915@xtg801> X-Mailer: exmh version 2.0delta 6/3/97 To: ibis@eda.org, ibis-users@eda.org Subject: EIA/IBIS Summit Meeting -- Call For Presentations Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 20 May 1998 16:19:32 -0700 From: Stephen Peters D A C I B I S S U M M I T M E E T I N G DATE: Thursday, June 18, 1998 TIME: 9 AM - Afternoon LOCATION: San Francisco Marriott Hotel, next to Moscone Center where the Design Automation Conference (DAC) is being held ROOM: Pacific 4-1 LUNCH: Refreshments and Lunch will be provided. AGENDA: The main focus is to continue face-to-face technical discussions on IBIS Version 3.1 ratification issues. We may ratify IBIS Version 3.1 at this time. Also, we will be electing EIA IBIS Open Forum Officers for 1997-1998. The formal agenda will be developed and published before the meeting. CALL FOR PRESENTATIONS: We are open for presentations on any subject and may solicit a few presentations. We are also open to technical presentations related to the recent BIRDs and IBIS Version 3.0 features. Contact Stephen Peters regarding your presentation: Presenter: Title: Estimated Time: We would like you to provide handouts for the meeting (about 25) and also have an electronic copy. CALL FOR ATTENDEES: Please let Stephen Peters know if you are planning to attend so we have an estimate on food requirements. CONTACT: Stephen Peters sjpeters@ichips.intel.com ------- End of Forwarded Message From owner-ibis Thu May 21 03:23:05 1998 Received: from penguin.wise.edt.ericsson.se (penguin-ext.wise.edt.ericsson.se [194.237.142.5]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id DAA06276 for ; Thu, 21 May 1998 03:23:04 -0700 (PDT) Received: from alb1 (alb1-186.al.etx.ericsson.se [130.100.186.14]) by penguin.wise.edt.ericsson.se (8.7.5/8.7.3/penguin-1.12) with SMTP id MAA05940; Thu, 21 May 1998 12:16:23 +0200 (MET DST) Received: from alc2.al.etx.ericsson.se by alb1 (SMI-8.6/LME-2.2.6) id MAA21259; Thu, 21 May 1998 12:16:23 +0200 From: Anders.Ekholm@al.etx.ericsson.se (Anders Ekholm) Received: by alc2.al.etx.ericsson.se (SMI-8.6/client-1.6) id MAA10528; Thu, 21 May 1998 12:16:22 +0200 Date: Thu, 21 May 1998 12:16:22 +0200 Message-Id: <199805211016.MAA10528@alc2.al.etx.ericsson.se> To: crokusek@viewlogic.com, ibis@eda.org, bobr@emicx.mentorg.com Subject: Re: Can't do T-LINE? X-Sun-Charset: US-ASCII Excuse me, but wouldn't that mean that you only will be able to use one T-line segment as a package modell ? That would imply that the package is uniform, and I would suppose that most packages are not. To get an accurate model you need multiple T-line segment models. Is that not possible in IBIS 3.0 ? Best Regards /Anders Ekholm Ericsson Telecom > From owner-ibis@server.vhdl.org Wed May 20 04:46 MET 1998 > From: bobr@emicx.mentorg.com (Bob Ross) > Date: Tue, 19 May 98 19:03:38 PDT > To: crokusek@viewlogic.com, ibis@eda.org > Subject: Re: Can't do T-LINE? > Cc: bobr@emicx.mentorg.com > Mime-Version: 1.0 > X-Status: $$$$ > X-UID: 0000001041 > > Chris: > > The L, C, and R parameters are given as CORRESPONDING per unit length values. > These are multiplied by Len to produce the total distributed values for the > exact length of T-line that you want. > > Whenever Len is not equal to zero, the section is interpreted as > a distributed section (not a lumped section). > > The T-line relationships still hold: > > Zo = sqrt(L/C) > TD = Len * sqrt(LC) > > So the electrical information is available for a T-line of whatever length > you want. > > Best Regards, > Bob Ross > Interconnectix/Mentor Graphics > > > > Sender: crokusek@qdt.com > > Date: Tue, 19 May 1998 17:56:15 -0700 > > From: Chris Rokusek > > To: ibis@eda.org > > Subject: Can't do T-LINE? > > > ( I am reposting this question in hopes of a more helpful response ) > > > Hi All, > > > Concerning [Path Description] section in Ver 3.x of .ibs... > > > The 'len' parameter is given in 'units' which is 'arbitrary' (i.e. not > > meters) such that a distributed T-LINE model cannot be built with the > > proper physical length. > > > ** I DO NOT WANT TO BUILD A LUMPED MODEL, I WANT TO BUILD A T-LINE MODEL > > ** > > > Is this an oversight or am I not understanding the parameters? > > > Best Regards, > > > Chris Rokusek > > Viewlogic Systems > > > > > > > |============================================================================= > > | Keyword: [Path Description] > > | Required: Yes > > | Description: This keyword allows the user to describe the connection > > | between the user accessible pins of a part and the pins > > of the > > | ICs mounted on that part. Each pin to node connection > > is > > | divided into one or more cascaded "sections", where each > > | section is described in terms of it's L/R/C per unit > > length. > > | The Fork and Endfork subparameters allow the path to > > branch to > > | multiple nodes, or another pin. A path description is > > | required for each pin whose signal name is not "GND", > > "POWER" > > | or "NC". > > | > > | Board Description and IC Boundaries: > > | > > | In any system, each part interfaces with another part at > > some > > | boundary. Every part model must contain the components > > | necessary to represent the behavior of the part being > > modeled > > | within its boundaries. The boundary definition depends > > upon > > | the parts being represented by the model. > > | > > | For CARD EDGE CONNECTIONS such as a SIMM or a PC > > Daughter > > | Card plugged into a SIMM Socket or Edge Connector, the > > | boundary should be at the end of the board card edge > > pads as > > | they emerge from the connector. > > | > > | For any THROUGH-HOLE MOUNTED PART, the boundary will be > > at the > > | surface of the board on which the part is mounted. > > | > > | SURFACE MOUNTED PART models end at the outboard end of > > their > > | recommended surface mount pads. > > | > > | If the board level component contains an UNMATED > > CONNECTOR, > > | the unmated connector will be described in a separate > > file, > > | with its boundaries being as described above for the > > | through-hole or surface mounted part. > > | > > | Sub-Params: Len, L, R, C, Fork, Endfork, Pin, Node > > | Usage Rules: Each individual connection path (user pin to node(s)) > > | description begins with the [Path Description] keyword > > and a > > | path name, followed by the subparameters used to > > describe the > > | path topology and the electrical characteristics of each > > | section of the path. The path name must not exceed 40 > > | characters, blanks are not allowed, and each occurrence > > of the > > | [Path Description] keyword must be followed by a unique > > path > > | name. Every signal pin (pins other than POWER, GND or > > NC) > > | must appear in one and only one path description per > > [Begin > > | Board Description]/[End Board Description] pair. Pin > > names do > > | not have to appear in the same order as listed in the > > [Pin > > | List] table. The individual subparameters are broken up > > into > > | those that describe the electrical properties of a > > section, > > | and those that describe the topology of a path. > > | > > | Section Description Subparameters: > > | > > | The Len, L, R, and C subparameters specify the length, > > the > > | series inductance and resistance and the capacitance to > > ground > > | of each section in a path description. > > | > > | Len The physical length of a section. Lengths are > > given > > | in terms of arbitrary 'units'. Any non-zero > > length > > | requires that the parameters that follow must be > > | interpreted as distributed elements by the > > simulator. > > | L The series inductance of a section, in terms of > > | 'inductance/unit length'. For example, if the > > total > > | inductance of a section is 3.0 nH and the length > > of > > | the section is 2 'units', the inductance would > > be > > | listed as L = 1.5 nH (i.e. 3.0 / 2). > > | C The capacitance to ground of a section, in terms > > of > > | capacitance per unit length. > > | R The series DC (ohmic) resistance of a section, > > in > > | terms of ohms per unit length. > > | > > | Topology Description Subparameters: > > | > > | The Fork and Endfork subparameters denote branches from > > the > > | main pin-to-node or pin-to-pin connection path. The > > Node > > | subparameter is used to reference the pin of a component > > or > > | board as defined in a .ibs or .ebd file. The Pin > > subparameter > > | is used to indicate the point at which a path connects > > to a > > | user visible pin. > > | > > | Fork This subparameter indicates that the sections > > | following (up to the Endfork subparameter) are > > part > > | of a branch off of the main connection path. > > This > > | subparameter has no arguments. > > | Endfork This subparameter indicates the end point of a > > branch. > > | For every Fork subparameter there must be a > > | corresponding Endfork subparameter. As with the > > Fork > > | subparameter, the Endfork subparameter has no > > | arguments. > > | Node reference_designator.pin > > | This subparameter is used when the connection > > path > > | connects to a pin of another, externally defined > > part. > > | The arguments of the Node subparameter indicate > > the > > | pin and reference designator of the external > > | component. The pin and reference designator > > portions > > | of the argument are separated by a period > > ("."). The > > | reference designator is mapped to an external > > | component description (another .ebd file or .ibs > > file) > > | by the [Reference Designator Map] Keyword. Note > > that > > | a Node MUST reference a model of a passive or > > active > > | component. A Node is not an arbitrary > > connection > > | point between two elements or paths. > > | Pin This subparameter is used to mark the point at > > which > > | a path description connects to a user accessible > > pin. > > | Every path description must contain at least one > > | occurrence of the Pin subparameter. It may also > > | contain the reserved word NC. The value of the > > Pin > > | subparameter must be one of the pin names listed > > in > > | the [Pin List] section. > > | > > | Using The Subparameters to Describe Paths: > > | > > | A section description begins with the Len subparameter > > and > > | ends with the slash (/) character. The value of the > > Len, L, > > | R, and C subparameters and the subparameter itself are > > | separated by an equals sign (=); whitespace around the > > equals > > | sign is optional. The Fork, Endfork, Node and Pin > > | subparameters are placed between section descriptions > > (i.e., > > | between the concluding slash of one section and the > > 'Len' > > | parameters that starts another). The arguments of the > > Pin and > > | Node subparameter are separated by white space. > > | > > | Specifying a Len or L/R/C value of zero is allowed. If > > | Len = 0 is specified, then the L/R/C values are the > > total for > > | that section. If a non-zero length is specified, then > > the > > | total L/R/C for a section is calculated by multiplying > > the > > | value of the Len subparameter by the value of the L, R, > > or C > > | subparameter. However, as noted below, if a non-zero > > length > > | is specified, that section MUST be interpreted as > > distributed > > | elements. > > | > > | Legal Subparameter Combinations for Section > > Descriptions: > > | > > | A) Len, and one or more of the L, R and C > > subparameters. If > > | the Len subparameter is given as zero, then the L/R/C > > | subparameters represent lumped elements. If the Len > > | subparameter is non-zero, then the L/R/C subparameters > > | represent distributed elements and both L and C must be > > | specified, R is optional. > > | > > | B) The first subparameter following the [Path > > Description] > > | keyword must be 'Pin', followed by one or more section > > | descriptions. The path description can terminate in a > > Node, > > | another pin or the reserved word, NC. > > | > > | Dealing With Series Elements: > > | > > | A discrete series R or L component can be included in a > > path > > | description by defining a section with L=0 and the > > proper R or > > | L value. A discrete series component can also be > > included in > > | a path description by writing two back to back node > > statements > > | that reference the same component (see the example > > below). > > | Note that both ends of a discrete, two terminal > > component MUST > > | be contained in a single [Path Description]. Connecting > > two > > | separate [Path Description] with a series component is > > not > > | allowed. > > |----------------------------------------------------------------------------- > > | > > | An Example Path For a SIMM Module: > > | > > [Path Description] CAS_2 > > Pin J25 > > Len = 0.5 L=8.35n C=3.34p R=0.01 / > > Node u21.15 > > Len = 0.5 L=8.35n C=3.34p R=0.01 / > > Node u22.15 > > Len = 0.5 L=8.35n C=3.34p R=0.01 / > > Node u23.15 > > | > > | A Description Using The Fork and Endfork Subparameters: > > | > > [Path Description] PassThru1 > > Pin B5 > > Len = 0 L=2.0n / > > Len = 2.1 L=6.0n C=2.0p / > > Fork > > Len = 1.0 L = 1.0n C= 2.0p / > > Node u23.15 > > Endfork > > Len = 1.0 L = 6.0n C=2.0p / > > Pin A5 > > | > > | A Description Including a Discrete Series Element: > > | > > [Path Description] sig1 > > Pin B27 > > Len = 0 L=1.6n / > > Len = 1.5 L=6.0n C=2.0p / > > Node R2.1 > > Node R2.2 > > Len = 0.25 L=6.0n C=2.0p / > > Node U25.6 > > | > > |============================================================================= > > > From owner-ibis Thu May 21 08:30:21 1998 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id IAA11491 for ; Thu, 21 May 1998 08:30:20 -0700 (PDT) Received: from ichips-jf.jf.intel.com (ichips-jf.jf.intel.com [134.134.50.200]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id IAA19339; Thu, 21 May 1998 08:36:04 -0700 (PDT) Received: from xtg801 (xtg801.pdx.intel.com [134.134.120.169]) by ichips-jf.jf.intel.com (8.8.8/8.8.7) with ESMTP id IAA16926; Thu, 21 May 1998 08:27:00 -0700 (PDT) Received: from ichips.intel.com by xtg801 (8.8.8/WW2.1 (Jones Farm)) id IAA10951; Thu, 21 May 1998 08:26:59 -0700 (PDT) Message-Id: <199805211526.IAA10951@xtg801> X-Mailer: exmh version 2.0delta 6/3/97 To: Anders.Ekholm@al.etx.ericsson.se (Anders Ekholm) cc: ibis@eda.org Subject: Re: Can't do T-LINE? In-reply-to: Your message of "Thu, 21 May 1998 12:16:22 +0200." <199805211016.MAA10528@alc2.al.etx.ericsson.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 21 May 1998 08:26:58 -0700 From: Stephen Peters Anders Ekholm wrote: > Excuse me, but wouldn't that mean that you only will > be able to use one T-line segment as a package > modell ? > > That would imply that the package is uniform, and > I would suppose that most packages are not. To get > an accurate model you need multiple T-line segment > models. Is that not possible in IBIS 3.0 ? Multiple T-line segments are possible in the package description of IBIS 3.0. They are also available in the electrical board description. Regards, Stephen Peters Intel Corp. > > Best Regards /Anders Ekholm > Ericsson Telecom > > > > > From owner-ibis@server.vhdl.org Wed May 20 04:46 MET 1998 > > From: bobr@emicx.mentorg.com (Bob Ross) > > Date: Tue, 19 May 98 19:03:38 PDT > > To: crokusek@viewlogic.com, ibis@eda.org > > Subject: Re: Can't do T-LINE? > > Cc: bobr@emicx.mentorg.com > > Mime-Version: 1.0 > > X-Status: $$$$ > > X-UID: 0000001041 > > > > Chris: > > > > The L, C, and R parameters are given as CORRESPONDING per unit length values. > > These are multiplied by Len to produce the total distributed values for the > > exact length of T-line that you want. > > > > Whenever Len is not equal to zero, the section is interpreted as > > a distributed section (not a lumped section). > > > > The T-line relationships still hold: > > > > Zo = sqrt(L/C) > > TD = Len * sqrt(LC) > > > > So the electrical information is available for a T-line of whatever length > > you want. > > > > Best Regards, > > Bob Ross > > Interconnectix/Mentor Graphics > > > > > > > Sender: crokusek@qdt.com > > > Date: Tue, 19 May 1998 17:56:15 -0700 > > > From: Chris Rokusek > > > To: ibis@eda.org > > > Subject: Can't do T-LINE? > > > > > ( I am reposting this question in hopes of a more helpful response ) > > > > > Hi All, > > > > > Concerning [Path Description] section in Ver 3.x of .ibs... > > > > > The 'len' parameter is given in 'units' which is 'arbitrary' (i.e. not > > > meters) such that a distributed T-LINE model cannot be built with the > > > proper physical length. > > > > > ** I DO NOT WANT TO BUILD A LUMPED MODEL, I WANT TO BUILD A T-LINE MODEL > > > ** > > > > > Is this an oversight or am I not understanding the parameters? > > > > > Best Regards, > > > > > Chris Rokusek > > > Viewlogic Systems > > > > > > > > > > > |============================================================================= > > > | Keyword: [Path Description] > > > | Required: Yes > > > | Description: This keyword allows the user to describe the connection > > > | between the user accessible pins of a part and the pins > > > of the > > > | ICs mounted on that part. Each pin to node connection > > > is > > > | divided into one or more cascaded "sections", where each > > > | section is described in terms of it's L/R/C per unit > > > length. > > > | The Fork and Endfork subparameters allow the path to > > > branch to > > > | multiple nodes, or another pin. A path description is > > > | required for each pin whose signal name is not "GND", > > > "POWER" > > > | or "NC". > > > | > > > | Board Description and IC Boundaries: > > > | > > > | In any system, each part interfaces with another part at > > > some > > > | boundary. Every part model must contain the components > > > | necessary to represent the behavior of the part being > > > modeled > > > | within its boundaries. The boundary definition depends > > > upon > > > | the parts being represented by the model. > > > | > > > | For CARD EDGE CONNECTIONS such as a SIMM or a PC > > > Daughter > > > | Card plugged into a SIMM Socket or Edge Connector, the > > > | boundary should be at the end of the board card edge > > > pads as > > > | they emerge from the connector. > > > | > > > | For any THROUGH-HOLE MOUNTED PART, the boundary will be > > > at the > > > | surface of the board on which the part is mounted. > > > | > > > | SURFACE MOUNTED PART models end at the outboard end of > > > their > > > | recommended surface mount pads. > > > | > > > | If the board level component contains an UNMATED > > > CONNECTOR, > > > | the unmated connector will be described in a separate > > > file, > > > | with its boundaries being as described above for the > > > | through-hole or surface mounted part. > > > | > > > | Sub-Params: Len, L, R, C, Fork, Endfork, Pin, Node > > > | Usage Rules: Each individual connection path (user pin to node(s)) > > > | description begins with the [Path Description] keyword > > > and a > > > | path name, followed by the subparameters used to > > > describe the > > > | path topology and the electrical characteristics of each > > > | section of the path. The path name must not exceed 40 > > > | characters, blanks are not allowed, and each occurrence > > > of the > > > | [Path Description] keyword must be followed by a unique > > > path > > > | name. Every signal pin (pins other than POWER, GND or > > > NC) > > > | must appear in one and only one path description per > > > [Begin > > > | Board Description]/[End Board Description] pair. Pin > > > names do > > > | not have to appear in the same order as listed in the > > > [Pin > > > | List] table. The individual subparameters are broken up > > > into > > > | those that describe the electrical properties of a > > > section, > > > | and those that describe the topology of a path. > > > | > > > | Section Description Subparameters: > > > | > > > | The Len, L, R, and C subparameters specify the length, > > > the > > > | series inductance and resistance and the capacitance to > > > ground > > > | of each section in a path description. > > > | > > > | Len The physical length of a section. Lengths are > > > given > > > | in terms of arbitrary 'units'. Any non-zero > > > length > > > | requires that the parameters that follow must be > > > | interpreted as distributed elements by the > > > simulator. > > > | L The series inductance of a section, in terms of > > > | 'inductance/unit length'. For example, if the > > > total > > > | inductance of a section is 3.0 nH and the length > > > of > > > | the section is 2 'units', the inductance would > > > be > > > | listed as L = 1.5 nH (i.e. 3.0 / 2). > > > | C The capacitance to ground of a section, in terms > > > of > > > | capacitance per unit length. > > > | R The series DC (ohmic) resistance of a section, > > > in > > > | terms of ohms per unit length. > > > | > > > | Topology Description Subparameters: > > > | > > > | The Fork and Endfork subparameters denote branches from > > > the > > > | main pin-to-node or pin-to-pin connection path. The > > > Node > > > | subparameter is used to reference the pin of a component > > > or > > > | board as defined in a .ibs or .ebd file. The Pin > > > subparameter > > > | is used to indicate the point at which a path connects > > > to a > > > | user visible pin. > > > | > > > | Fork This subparameter indicates that the sections > > > | following (up to the Endfork subparameter) are > > > part > > > | of a branch off of the main connection path. > > > This > > > | subparameter has no arguments. > > > | Endfork This subparameter indicates the end point of a > > > branch. > > > | For every Fork subparameter there must be a > > > | corresponding Endfork subparameter. As with the > > > Fork > > > | subparameter, the Endfork subparameter has no > > > | arguments. > > > | Node reference_designator.pin > > > | This subparameter is used when the connection > > > path > > > | connects to a pin of another, externally defined > > > part. > > > | The arguments of the Node subparameter indicate > > > the > > > | pin and reference designator of the external > > > | component. The pin and reference designator > > > portions > > > | of the argument are separated by a period > > > ("."). The > > > | reference designator is mapped to an external > > > | component description (another .ebd file or .ibs > > > file) > > > | by the [Reference Designator Map] Keyword. Note > > > that > > > | a Node MUST reference a model of a passive or > > > active > > > | component. A Node is not an arbitrary > > > connection > > > | point between two elements or paths. > > > | Pin This subparameter is used to mark the point at > > > which > > > | a path description connects to a user accessible > > > pin. > > > | Every path description must contain at least one > > > | occurrence of the Pin subparameter. It may also > > > | contain the reserved word NC. The value of the > > > Pin > > > | subparameter must be one of the pin names listed > > > in > > > | the [Pin List] section. > > > | > > > | Using The Subparameters to Describe Paths: > > > | > > > | A section description begins with the Len subparameter > > > and > > > | ends with the slash (/) character. The value of the > > > Len, L, > > > | R, and C subparameters and the subparameter itself are > > > | separated by an equals sign (=); whitespace around the > > > equals > > > | sign is optional. The Fork, Endfork, Node and Pin > > > | subparameters are placed between section descriptions > > > (i.e., > > > | between the concluding slash of one section and the > > > 'Len' > > > | parameters that starts another). The arguments of the > > > Pin and > > > | Node subparameter are separated by white space. > > > | > > > | Specifying a Len or L/R/C value of zero is allowed. If > > > | Len = 0 is specified, then the L/R/C values are the > > > total for > > > | that section. If a non-zero length is specified, then > > > the > > > | total L/R/C for a section is calculated by multiplying > > > the > > > | value of the Len subparameter by the value of the L, R, > > > or C > > > | subparameter. However, as noted below, if a non-zero > > > length > > > | is specified, that section MUST be interpreted as > > > distributed > > > | elements. > > > | > > > | Legal Subparameter Combinations for Section > > > Descriptions: > > > | > > > | A) Len, and one or more of the L, R and C > > > subparameters. If > > > | the Len subparameter is given as zero, then the L/R/C > > > | subparameters represent lumped elements. If the Len > > > | subparameter is non-zero, then the L/R/C subparameters > > > | represent distributed elements and both L and C must be > > > | specified, R is optional. > > > | > > > | B) The first subparameter following the [Path > > > Description] > > > | keyword must be 'Pin', followed by one or more section > > > | descriptions. The path description can terminate in a > > > Node, > > > | another pin or the reserved word, NC. > > > | > > > | Dealing With Series Elements: > > > | > > > | A discrete series R or L component can be included in a > > > path > > > | description by defining a section with L=0 and the > > > proper R or > > > | L value. A discrete series component can also be > > > included in > > > | a path description by writing two back to back node > > > statements > > > | that reference the same component (see the example > > > below). > > > | Note that both ends of a discrete, two terminal > > > component MUST > > > | be contained in a single [Path Description]. Connecting > > > two > > > | separate [Path Description] with a series component is > > > not > > > | allowed. > > > |----------------------------------------------------------------------------- > > > | > > > | An Example Path For a SIMM Module: > > > | > > > [Path Description] CAS_2 > > > Pin J25 > > > Len = 0.5 L=8.35n C=3.34p R=0.01 / > > > Node u21.15 > > > Len = 0.5 L=8.35n C=3.34p R=0.01 / > > > Node u22.15 > > > Len = 0.5 L=8.35n C=3.34p R=0.01 / > > > Node u23.15 > > > | > > > | A Description Using The Fork and Endfork Subparameters: > > > | > > > [Path Description] PassThru1 > > > Pin B5 > > > Len = 0 L=2.0n / > > > Len = 2.1 L=6.0n C=2.0p / > > > Fork > > > Len = 1.0 L = 1.0n C= 2.0p / > > > Node u23.15 > > > Endfork > > > Len = 1.0 L = 6.0n C=2.0p / > > > Pin A5 > > > | > > > | A Description Including a Discrete Series Element: > > > | > > > [Path Description] sig1 > > > Pin B27 > > > Len = 0 L=1.6n / > > > Len = 1.5 L=6.0n C=2.0p / > > > Node R2.1 > > > Node R2.2 > > > Len = 0.25 L=6.0n C=2.0p / > > > Node U25.6 > > > | > > > |============================================================================= > > > > > > From owner-ibis Thu May 21 15:45:53 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id PAA18097 for ; Thu, 21 May 1998 15:45:52 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id PAA15930; Thu, 21 May 1998 15:42:04 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id PAA06478; Thu, 21 May 1998 15:42:04 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA26458; Thu, 21 May 98 15:42:03 PDT Date: Thu, 21 May 98 15:42:03 PDT Message-Id: <9805212242.AA26458@bob> To: ibis@eda.org Subject: IBIS BIRD48.2 Add Model 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. ****************************************************************************** From owner-ibis Thu May 21 15:47:01 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id PAA18102 for ; Thu, 21 May 1998 15:47:01 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id PAA16065; Thu, 21 May 1998 15:43:13 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id PAA06492; Thu, 21 May 1998 15:43:13 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA26461; Thu, 21 May 98 15:43:12 PDT Date: Thu, 21 May 98 15:43:12 PDT Message-Id: <9805212243.AA26461@bob> To: ibis@eda.org Subject: IBIS BIRD49.2 - Add Model Dynamic Clamps IBIS Folks: Based on discussions at the May 15, 1998 IBIS meeting and directly with with Arpad Muranyi and Neven Orhanovic, some additional changes are presented. The framework for changes were introduced in BIRD49.1. The refinements and considerations are: Make [Add Model Spec] and the [GND Pulse Table] and [POWER Pulse Table] optional. Eliminate the requirement for negative time as the indicator for externally triggered dynamic clamp operations. With these additons, the dynamic clamp modes of operation can be listed: [Add Model Spec] Pulse Table Yes Yes Triggered Dynamic Clamp No Yes Emulation of Clocked Dynamic Clamp Yes or No No Fixed Clamp Editorial Changes and corrections are made. Some sections are rewritten. See BIRD49.1 for the prior version of the text. A large portion of the BIRD49.2 text has been rewritten, so changes are not noted. Bob Ross Interconnectix/Mentor Graphics ****************************************************************************** ****************************************************************************** BIRD ID#: 49.2 ISSUE TITLE: Add Model Dynamic Clamps 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 novel type of termination technique is used in today's integrated circuits. The termination consists of a pair of built in dynamic clamps whose V-I curves change with time. The clamp is switched "on" when needed and switched "off" otherwise (to conserve power). When the clamp is switched "on" its V-I curve provides more clamping than a regular static clamp and when it is turned "off" it behaves like a normal clamp. The "on" switching of the dynamic clamps can be triggered by an input signal crossing a triggering threshold or by some external clock. The "off" switching can be triggered by a built in timer or an external clock. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The dynamic clamp functionality is added in the new Section 6a discussion: | Dynamic Clamp: | | When the Model_type subparameter under the [Model] keyword is set to | Dynamic_clamp, the added model describes the dynamic clamp functionality. | This section introduces the dynamic clamp add model functionality. | | The [GND Pulse Table] and [POWER Pulse Table] keywords are defined. An | example for a complete dynamic clamp model is provided. | |============================================================================= | Keyword: [GND Pulse Table], [POWER Pulse Table] | Required: No | Description: Used to specify the offset voltage versus time of [GND Clamp] | and [POWER Clamp] tables within added models. | Usage Rules: Each [GND Pulse Table] and [POWER Pulse Table] keyword | introduces a table of time versus vs. points that describe | the shape of an offset voltage from the [GND Clamp Reference] | voltage (or default ground) or the [POWER Clamp Reference] | voltage (or default [Voltage Range] voltage). | | The table itself | consists of one column of time points, then three columns of | voltage points in the standard typ, min, and max format. The | four entries must be placed on a single line and must be | separated by at least one white space or tab character. All | four columns are required. However, data is only required in | the typical column. If minimum or maximum data is not | available, use the reserved word "NA". Time values must | increase as one | parses down the table. The waveform table can contain a | maximum of 100 data points. | | Each table must contain at least two | entries. Thus, numerical values are required for the first | and last entries of any column containing numerical data. | | The voltage entries in both the [Gnd Pulse Table] and [POWER | Pulse Table] tables are directly measured offsets. | At each instance, the [Gnd Pulse Table] voltage is ADDED to | the [GND Clamp] table voltages to provide the shifted table | voltages. At each instance, [POWER Pulse Table] voltage is | SUBTRACTED (because of polarity conventions) from the [POWER | Clamp] table voltages to provide the shifted table voltages. | | Only one [GND Pulse Table] and | one [POWER Pulse Table] are allowed per model. | | The [GND Pulse Table] and [POWER Pulse Table] interact with | [Add Model Spec] subparameters V_trigger_f and V_trigger_r. | Several modes of operation exist based on whether a pulse | table and its corresponding trigger subparameter are given. | These modes are classified as triggered, clocked, and static. | | Triggered Mode: | | For triggered mode a pulse table must exist and include | the entire waveform; i.e., the | first entry (or entries) in a voltage column must be equal | to the last entry. | | Also, a corresponding [Add Model Spec] V_trigger_* | subparameter must exist. The triggered interaction is | described: | | The V_trigger_f subparameter under [Add Model Spec] is used | to detect when the falling edge waveform at the die passes | the trigger voltage. At that time the [Gnd Pulse Table] | operation starts. Similarily, the V_trigger_r subparameter is | used to detect when the rising edge waveform at the die passes | the trigger voltage. At that time [POWER Pulse Table] | operation starts. The [GND Pulse Table] dependency is shown | below: | | | Waveform at Die | | o o o o | o | o | o ------- | |o ^ | | o | V_trigger_f | | o v time | | o o--------------------> | | | | | | [GND Pulse Table] | | | | o o o o | | o o | | o o | | o o | | o o | | o o time | o o o o o o o o --------> | | ^ | |_ [GND Pulse Table] operation starts at this time | | The V_trigger_r and [POWER Pulse Table] operate in a similar manner. | When the V_trigger_r voltage value is reached on the rising edge, the | [POWER Pulse Table] is started. Normally the offset voltage entries in | the [Power Pulse Table are negative. | | Clocked Mode: | | A mode of operation that does not depend on the V_trigger_f or V_trigger_r | is described here. The intent is to allow the simulation of the dynamic | clamp effect when the dynamic clamp operation is controlled by an external | clock signal, usually to activate it before the signal on the net arrives. | | The clocked mode of operation is signaled by the existance of a pulse | table and by the lack of a corresponding V_trigger_* subparameter or | by the missing [Add Model Spec] keyword. | | When the EDA tool simulation pulse begins a low-to-high transition | the [POWER Pulse Table] begins. The initial (time zero) | voltage may already be a non-zero value. Similarly, when the EDA tool | simulation pulse begins a high-to-low transition, the [GND Pulse Table] | begins. | | Static Mode: | | When the [GND Pulse Table] keyword does not exist, but the added model | [GND Clamp] table does exist, the added model [GND Clamp] is used directly. | Similarly, when the [POWER Pulse Table] keyword does not exist, but the | added model [POWER Clamp] table does exist, the added model [POWER Clamp] | is used directly. | | This mode provides additional fixed clamping to an I/O_* buffer or a | 3-state buffer when it is used as a driver. |------------------------------------------------------------------------------ | | Example of Dynamic_clamp Model with both dynamic GND and POWER clamps: | [Model] Dynamic_Clamp_1 Model_type Dynamic_clamp C_comp 0 0 0 | [Add Model Spec] | Subparameter typ min max | V_trigger_f 1.4 1.2 1.6 | Falling edge trigger V_trigger_r 3.6 2.9 4.3 | Rising edge trigger | [GND Pulse Table] | GND Clamp offset table | Time V(typ) V(min) V(max) | | 0 0 0 0 | 1e-9 0 0 0 | 2e-9 0.9 0.8 1.0 | 10e-9 0.9 0.8 1.0 | 11e-9 0 0 0 | [GND Clamp] | Table to be offset | | Voltage I(typ) I(min) I(max) | -5.000 -3.300e+01 -3.000e+01 -3.500e+01 -4.000 -2.300e+01 -2.200e+01 -2.400e+01 -3.000 -1.300e+01 -1.200e+01 -1.400e+01 -2.000 -3.000e+00 -2.300e+00 -3.700e+00 -1.900 -2.100e+00 -1.500e+00 -2.800e+00 -1.800 -1.300e+00 -8.600e-01 -1.900e+00 -1.700 -6.800e-01 -4.000e-01 -1.100e+00 -1.600 -2.800e-01 -1.800e-01 -5.100e-01 -1.500 -1.200e-01 -9.800e-02 -1.800e-01 -1.400 -7.500e-02 -7.100e-02 -8.300e-02 -1.300 -5.750e-02 -5.700e-02 -5.900e-02 -1.200 -4.600e-02 -4.650e-02 -4.550e-02 -1.100 -3.550e-02 -3.700e-02 -3.450e-02 -1.000 -2.650e-02 -2.850e-02 -2.500e-02 -0.900 -1.850e-02 -2.100e-02 -1.650e-02 -0.800 -1.200e-02 -1.400e-02 -9.750e-03 -0.700 -6.700e-03 -8.800e-03 -4.700e-03 -0.600 -3.000e-03 -4.650e-03 -1.600e-03 -0.500 -9.450e-04 -1.950e-03 -3.650e-04 -0.400 -5.700e-05 -2.700e-04 -5.550e-06 -0.300 -1.200e-06 -1.200e-05 -5.500e-08 -0.200 -3.000e-08 -5.000e-07 0.000e+00 -0.100 0.000e+00 0.000e+00 0.000e+00 0.000 0.000e+00 0.000e+00 0.000e+00 5.000 0.000e+00 0.000e+00 0.000e+00 | [POWER Pulse Table] | POWER Clamp offset table | | Time V(typ) V(min) V(max) | | 0 0 0 0 | 1e-9 0 0 0 | 2e-9 -0.9 -1.0 -0.8 | 10e-9 -0.9 -1.0 -0.8 | 11e-9 0 0 0 | [POWER Clamp] | Table to be offset | | Voltage I(typ) I(min) I(max) | -5.000 1.150e+01 1.100e+01 1.150e+01 -4.000 7.800e+00 7.500e+00 8.150e+00 -3.000 4.350e+00 4.100e+00 4.700e+00 -2.000 1.100e+00 8.750e-01 1.300e+00 -1.900 8.000e-01 6.050e-01 1.000e+00 -1.800 5.300e-01 3.700e-01 7.250e-01 -1.700 2.900e-01 1.800e-01 4.500e-01 -1.600 1.200e-01 6.850e-02 2.200e-01 -1.500 3.650e-02 2.400e-02 6.900e-02 -1.400 1.200e-02 1.100e-02 1.600e-02 -1.300 6.300e-03 6.650e-03 6.100e-03 -1.200 4.200e-03 4.750e-03 3.650e-03 -1.100 2.900e-03 3.500e-03 2.350e-03 -1.000 1.900e-03 2.450e-03 1.400e-03 -0.900 1.150e-03 1.600e-03 7.100e-04 -0.800 5.500e-04 9.150e-04 2.600e-04 -0.700 1.200e-04 4.400e-04 5.600e-05 -0.600 5.400e-05 1.550e-04 1.200e-05 -0.500 1.350e-05 5.400e-05 1.300e-06 -0.400 8.650e-07 7.450e-06 4.950e-08 -0.300 6.250e-08 7.550e-07 0.000e+00 -0.200 0.000e+00 8.400e-08 0.000e+00 -0.100 0.000e+00 0.000e-08 0.000e+00 0.000 0.000e+00 0.000e+00 0.000e+00 | |============================================================================== ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: The proposal is designed to retain as much of the existing IBIS clamp syntax as possible. The dynamic clamp V-I curve tables follow all of the conventions of the existing V-I tables. The overall modeling approach is to decompose the dynamic clamp into its static and dynamic portions. The static part can be modeled by a regular clamp. The dynamic part is connected to the same rail voltage as its static part and modeled by a V-I curve that is shifted along the voltage axis by the offset voltage pulse. BIRD49 replaces the BIRD45.1 proposal of some new keywords shown below, but preserves the intended functionality. It also reponses to the comment that some of the V_trigger subparameters should be expressed in a typ-min-max format. The [Model Spec] keyword structure is proposed to do this. The replaced structure is below. |============================================================================== | Keywords: [Dynamic GND Clamp], [Dynamic POWER Clamp] | Required: No. | Description: Describes ground and power clamps that are switched on and off | dynamically. | | Subparameters: V_trigger, V_trigger_min, V_trigger_max | | Usage Rules: The [Dynamic GND Clamp] and [Dynamic PWR Clamp] specifications | contain three subparameters and two keywords. The subparameters | (V_trigger, V_trigger_min, V_trigger_max) specify the threshold | clamp voltage value that causes the clamp to begin switching | from "off" to "on" according to the [Pulse Table] section. | These values correspond to the typical, weak (slow), and strong | (fast) situations. The [Pulse Table] section describes the | switching characteristics of the dynamic clamp, and the [Clamp | Table] section gives the V-I table of the clamp in its "off" | state. This data is used as follows. | | A dynamic clamp is modeled by a V-I curve that is offset | (translated) along the voltage axis with the voltage waveform | given in the [Pulse Table] section. The resulting dynamic V-I | curve can be expressed as | | I = f( V - V_pulse(t) ), | | where V_pulse(t) is the offset voltage waveform described by | the [Pulse Table] section and f(V) is the resulting V-I curve | of the clamp in its off state, corresponding to the data | given in the [Clamp Table] section. The [Clamp Table] data | follows the same format and rules as the V-I curve data of | the corresponding regular ground or power clamp ([GND Clamp], | [POWER Clamp]). The [Pulse Table] section describes the offset | voltage waveform and uses the same format as the [Rising | Waveform] and [Falling Waveform] sections in driver models. | | Once the voltage on the clamp crosses the triggering threshold, | the [Pulse Table] data is used to offset the V-I curve obtained | from the [Clamp Table] section. The dependence of the offset | pulse on the clamp voltage is illustrated below. | | | Clamp voltage vs. time. | | o o o o | o | o | o ------- | o| ^ | o | | V_trigger | o | v time | o o | ------------------------> | | | | | | | | Clamp offset voltage vs. time. | | | | o o o o | | o o | | o o | | o o o o o | | o o | | o o time | o o o o o o o o --------> | | ^ | |_ Pulse data is used from this moment on | to offset the V-I curve. | | |------------------------------------------------------------------------------ | | Example: | [Dynamic GND Clamp] | V_trigger = 1.4V V_trigger_min = 1.2V V_trigger_max = 1.6V | [Pulse Table] | | Time V(typ) V(min) V(max) | | 0 0 0 0 | 1e-9 0 0 0 | 2e-9 0.9 0.8 1.0 | 10e-9 0.9 0.8 1.0 | 11e-9 0 0 0 | [Clamp Table] | | Voltage I(typ) I(min) I(max) | -5.000 -3.300e+01 -3.000e+01 -3.500e+01 -4.000 -2.300e+01 -2.200e+01 -2.400e+01 -3.000 -1.300e+01 -1.200e+01 -1.400e+01 -2.000 -3.000e+00 -2.300e+00 -3.700e+00 -1.900 -2.100e+00 -1.500e+00 -2.800e+00 -1.800 -1.300e+00 -8.600e-01 -1.900e+00 -1.700 -6.800e-01 -4.000e-01 -1.100e+00 -1.600 -2.800e-01 -1.800e-01 -5.100e-01 -1.500 -1.200e-01 -9.800e-02 -1.800e-01 -1.400 -7.500e-02 -7.100e-02 -8.300e-02 -1.300 -5.750e-02 -5.700e-02 -5.900e-02 -1.200 -4.600e-02 -4.650e-02 -4.550e-02 -1.100 -3.550e-02 -3.700e-02 -3.450e-02 -1.000 -2.650e-02 -2.850e-02 -2.500e-02 -0.900 -1.850e-02 -2.100e-02 -1.650e-02 -0.800 -1.200e-02 -1.400e-02 -9.750e-03 -0.700 -6.700e-03 -8.800e-03 -4.700e-03 -0.600 -3.000e-03 -4.650e-03 -1.600e-03 -0.500 -9.450e-04 -1.950e-03 -3.650e-04 -0.400 -5.700e-05 -2.700e-04 -5.550e-06 -0.300 -1.200e-06 -1.200e-05 -5.500e-08 -0.200 -3.000e-08 -5.000e-07 0.000e+00 -0.100 0.000e+00 0.000e+00 0.000e+00 0.000 0.000e+00 0.000e+00 0.000e+00 5.000 0.000e+00 0.000e+00 0.000e+00 | | [Dynamic POWER Clamp] | V_trigger = 3.6V V_trigger_min = 3.8V V_trigger_max = 3.4V | [Pulse Table] | | Time V(typ) V(min) V(max) | | 0 0 0 0 | 1e-9 0 0 0 | 2e-9 -0.9 -1.0 -0.8 | 10e-9 -0.9 -1.0 -0.8 | 11e-9 0 0 0 | [Clamp Table] | | Voltage I(typ) I(min) I(max) | -5.000 1.150e+01 1.100e+01 1.150e+01 -4.000 7.800e+00 7.500e+00 8.150e+00 -3.000 4.350e+00 4.100e+00 4.700e+00 -2.000 1.100e+00 8.750e-01 1.300e+00 -1.900 8.000e-01 6.050e-01 1.000e+00 -1.800 5.300e-01 3.700e-01 7.250e-01 -1.700 2.900e-01 1.800e-01 4.500e-01 -1.600 1.200e-01 6.850e-02 2.200e-01 -1.500 3.650e-02 2.400e-02 6.900e-02 -1.400 1.200e-02 1.100e-02 1.600e-02 -1.300 6.300e-03 6.650e-03 6.100e-03 -1.200 4.200e-03 4.750e-03 3.650e-03 -1.100 2.900e-03 3.500e-03 2.350e-03 -1.000 1.900e-03 2.450e-03 1.400e-03 -0.900 1.150e-03 1.600e-03 7.100e-04 -0.800 5.500e-04 9.150e-04 2.600e-04 -0.700 1.200e-04 4.400e-04 5.600e-05 -0.600 5.400e-05 1.550e-04 1.200e-05 -0.500 1.350e-05 5.400e-05 1.300e-06 -0.400 8.650e-07 7.450e-06 4.950e-08 -0.300 6.250e-08 7.550e-07 0.000e+00 -0.200 0.000e+00 8.400e-08 0.000e+00 -0.100 0.000e+00 0.000e-08 0.000e+00 0.000 0.000e+00 0.000e+00 0.000e+00 | |============================================================================== BIRD49.1 adds the rules for when the time is negative and when the V_trigger_l and V_trigger_h thresholds are not used and can be omitted. The intent is to support having the dynamic clamps controlled by an external control so that they can be preset before the signal arrives at the device. A method was chosen that is based on the activation pulse that the simulator uses to initiate the driver transition. Most simulators do not have an independent pulse control to preset some other parameter. This method can be user configurable to deal with simulator differences in time relationships for driver activation on the net and possible phase differences of this component on a net. The time values may have to be readjusted for a particular part. However, the approach taken here should work for most practical cases. BIRD49.2 simplifies extends and simplifies the rules. Several modes of operation are defined based on the existance of non-existency of the [Add Model Spec] trigger subparameters (or keyword itself) and also for when the pulse table itself is missing. The dependency on an artificial negative time for one of the modes of operation in BIRD49.1 was not appealing. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: Based on a conversation with Arpad Muranyi on 11/14/97. Modified per a discussion with Bob Ross, Chris Reid and Arpad Muranyi on March 11, 1998. ****************************************************************************** From owner-ibis Thu May 21 15:48:25 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id PAA18220 for ; Thu, 21 May 1998 15:48:25 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id PAA16118; Thu, 21 May 1998 15:44:38 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id PAA06508; Thu, 21 May 1998 15:44:37 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA26464; Thu, 21 May 98 15:44:36 PDT Date: Thu, 21 May 98 15:44:36 PDT Message-Id: <9805212244.AA26464@bob> To: ibis@eda.org Subject: IBIS BIRD50.1 Add Model Bus Hold Dear IBIS Folks: BIRD50 describes a bus hold extension which is also useful for other similar structures. BIRD50.1 is issued with these changes: The title is corrected. [Add Model Spec] is required for bus hold models Add_model_mode is illustrated Any other minor editorial correction Changes occurred or are documemented in the |* lines. Bob Ross Interconnectix/Mentor Graphics ****************************************************************************** ****************************************************************************** BIRD ID#: 50.1 ISSUE TITLE: Add Model Bus Hold REQUESTER: Neven Orhanovic, Bob Ross, Mentor G., Arpad Muranyi, Intel DATE SUBMITTED: 4/2/98, 5/21/98 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: New devices incorporate bus hold or other latching mechanisms to hold the input at a particular state using some active pullup and pulldown components. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The Bus Hold functionality is added in the new Section 6a: | Bus Hold: | |* When the Model_type subparameter under the [Model] keyword is set to |* Bus_hold, the added model describes the bus hold functionality. This |* section introduces the dynamic clamp add model functionality. | |* Existing keywords and subparameters are used to describe bus hold models. |* The [Pullup] and [Pulldown] tables both are used to define a weak internal |* buffer that is triggered switch to its opposite state. This switching |* transition is specified by a [Ramp] keyword or by the [Rising Waveform] |* and [Falling Waveform] keywords. |* |* For bus hold models, the [Add Model Spec] and V_trigger_r and V_trigger_f |* subparameters are required. | | The transition is triggered by action at the die using the [Add Model Spec] | V_trigger_r and V_trigger_f subparameters as follows: | |* If the starting voltage is below V_trigger_f, then the bus_hold model is |* set to the low state causing additional pulldown current. If the starting |* voltage is above V_trigger_r, the bus hold model is set to the high | state for additional pullup current. When the input passes though | V_trigger_f during a high-to-low transition at the die, the bus hold output |* switches to the low state. Similarly, when the input passes though |* V_trigger_r during a low-to_high transition at the die, the bus hold output |* switches to the high state. | | No additional keywords are needed for this functionality. |------------------------------------------------------------------------------ | | Complete Bus_hold Model Example: | [Model] Bus_hold_1 Model_type Bus_hold C_comp 0 0 0 | |* Add Model_Mode added to the example in the next three lines: Add_Model_Mode Non-Driving | Illustrates constraining this additional | functionalily to non-driving modes of | operation [Add Model Spec] | Subparameter typ min max | V_trigger_f 1.3 1.2 1.4 | Falling edge trigger V_trigger_r 3.1 2.6 4.6 | Rising edge trigger | [Pulldown] | -5V -100uA -80uA -120uA -1V -30uA -25uA -40uA 0V 0 0 0 1V 30uA 25uA 40uA 3V 50uA 45uA 50uA 5V 100uA 80uA 120uA 10v 120uA 90uA 150uA | [Pullup] | -5V 100uA 80uA 120uA -1V 30uA 25uA 40uA 0V 0 0 0 1V -30uA -25uA -40uA 3V -50uA -45uA -50uA 5V -100uA -80uA -120uA 10v -120uA -90uA -150uA | |**************************************************************************** | [Ramp] | typ min max dV/dt_r 2.0/0.50n 2.0/0.75n 2.0/0.35n dV/dt_f 2.0/0.50n 2.0/0.75n 2.0/0.35nn | |**************************************************************************** |============================================================================== ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: A weak driver can be added using the [Add Model] keyword. BIRD50.1 adds the statement that [Add Model Spec] and its V_trigger_r and V_trigger_f subparameters are required. This is because [Add Model Spec] may not be required for other added models. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: This proposal is based on a conversation with Bob Ross, Chris Reid, and Arpad Muranyi on March 11, 1998. ****************************************************************************** From owner-ibis Fri May 22 23:57:41 1998 Received: from relayhost.vlsi.com (relayhost.vlsi.com [134.27.20.24]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id XAA19621 for ; Fri, 22 May 1998 23:57:41 -0700 (PDT) Received: (from nobody@localhost) by relayhost.vlsi.com (SMI-8.6/Hub-Perlotto/050895) id XAA10513 for ; Fri, 22 May 1998 23:53:52 -0700 Received: from (relayhost.sanjose.vlsi.com [134.27.58.1]) by isis.vlsi.com via smap (V2.0) id xma010488; Fri, 22 May 98 23:53:41 -0700 Received: from sanjose.vlsi.com (daml.sanjose.vlsi.com [134.27.44.3]) by relayhost.sanjose.vlsi.com (8.6.9/Hub-Anderson/111497) with SMTP id XAA10897 for ; Fri, 22 May 1998 23:53:40 -0700 Received: from hdsl by sanjose.vlsi.com (4.1/Hub-Anderson/030398) id AA02587; Fri, 22 May 98 14:35:30 PDT From: kulwant.brar@vlsi.com (Kulwant Brar) Received: by hdsl id OAA10886; Fri, 22 May 1998 14:35:29 -0700 Date: Fri, 22 May 1998 14:35:29 -0700 Message-Id: <199805222135.OAA10886@hdsl> To: ibis@vhdl.org Subject: subscribe Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Md5: GSzpP+hym2wAhoxwHl6teA== Hi, Could you please add my name to the distribution list for the IBIS reflector. Thank you. Kulwant.brar@vlsi.com Kulwant Brar Applications Engineer Network Products Division VLSI Technology From owner-ibis Sun May 24 18:18:05 1998 Received: from hqexchg.aztech.com.sg (hqexchg.aztech.com.sg [203.120.164.34]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id SAA00201 for ; Sun, 24 May 1998 18:18:02 -0700 (PDT) Received: by HQEXCHG with Internet Mail Service (5.0.1458.49) id ; Mon, 25 May 1998 09:13:59 +0800 Message-ID: <3247FF801D16D111B5D300A024CC3A2901099082@HQEXCHG> From: Zhang Zhen Yu - R&D To: ibis@vhdl.org Subject: unsubscribe Date: Mon, 25 May 1998 09:13:56 +0800 X-Priority: 3 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.0.1458.49) Content-Type: text/plain unsubscribe From owner-ibis Mon May 25 06:55:09 1998 Received: from TYO2.gate.nec.co.jp (TYO2.gate.nec.co.jp [203.180.98.33]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id GAA13379 for ; Mon, 25 May 1998 06:55:07 -0700 (PDT) Received: from mailsv.nec.co.jp ([192.168.1.90]) by TYO2.gate.nec.co.jp (8.8.8+2.7Wbeta7/3.6Wbeta698051415) with ESMTP id WAA03757 for ; Mon, 25 May 1998 22:51:47 +0900 (JST) Received: from askcs42.asic.lsi.nec.co.jp ([133.202.84.78]) by mailsv.nec.co.jp (8.8.8+2.7Wbeta7/3.6Wbeta6-98052215) with ESMTP id WAA04460 for ; Mon, 25 May 1998 22:51:46 +0900 (JST) Received: (from narita@localhost) by askcs42.asic.lsi.nec.co.jp (8.8.5+2.7Wbeta5/3.5Wpl7lsi_mx_5.0) id WAA25578; Mon, 25 May 1998 22:46:09 +0900 (JST) Message-Id: <199805251346.WAA25578@askcs42.asic.lsi.nec.co.jp> To: ibis@vhdl.org Subject: unsubscribe From: NARITA Nobuyuki Reply-To: narita@lsi.nec.co.jp X-Mailer: Mew version 1.70 on Emacs 19.28.1 / Mule 2.3 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Mon, 25 May 1998 22:46:09 +0900 Sender: narita@askcs42.asic.lsi.nec.co.jp unsubscribe From owner-ibis Wed May 27 12:12:09 1998 Received: from ganymede.or.intel.com (ganymede.or.intel.com [134.134.248.3]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id MAA08668 for ; Wed, 27 May 1998 12:12:09 -0700 (PDT) From: JPATEL%FUNIES@VMSGATE.INTEL.COM Received: from orsmsx27.INTEL.COM (orsmsx27.jf.intel.com [192.168.74.27]) by ganymede.or.intel.com (8.8.6/8.8.5) with ESMTP id MAA08733 for ; Wed, 27 May 1998 12:17:37 -0700 (PDT) Received: from vmsgate.intel.com ([132.233.190.24]) by orsmsx27.INTEL.COM with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.1960.3) id LY323A6S; Wed, 27 May 1998 12:08:57 -0700 Received: from DECNET-MAIL (JPATEL@FUNIES) by VMSGATE.INTEL.COM (PMDF V5.1-7 #23336) id <01IXJ0241ABK0001EG@VMSGATE.INTEL.COM> for ibis@eda.org; Wed, 27 May 1998 12:09:38 PST Date: Wed, 27 May 1998 12:09:38 -0800 (PST) Subject: Change of my E-mail address To: ibis@eda.org Message-id: <01IXJ0241JYQ0001EG@VMSGATE.INTEL.COM> X-VMS-To: SM::"ibis@eda.org" MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Please change my E-mail from: jpatel@funies.enet.dec.com to jpatel%pasta@VMSGATE.INTEL.COM Thanks, Jash From owner-ibis Fri May 29 10:53:08 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id KAA26775 for ; Fri, 29 May 1998 10:53:07 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id KAA01263; Fri, 29 May 1998 10:49:17 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id KAA06568; Fri, 29 May 1998 10:49:14 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA02730; Fri, 29 May 98 10:49:14 PDT Date: Fri, 29 May 98 10:49:14 PDT Message-Id: <9805291749.AA02730@bob> To: ibis@eda.org Subject: BIRD48.3 - Add Model 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. ****************************************************************************** From owner-ibis Fri May 29 10:56:51 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id KAA26796 for ; Fri, 29 May 1998 10:56:50 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id KAA01578; Fri, 29 May 1998 10:53:00 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id KAA06600; Fri, 29 May 1998 10:52:57 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA02733; Fri, 29 May 98 10:52:57 PDT Date: Fri, 29 May 98 10:52:57 PDT Message-Id: <9805291752.AA02733@bob> To: ibis@eda.org Subject: BIRD50.2 - Add Model Bus Hols Dear IBIS Folks: BIRD50 describes a bus hold extension which is also useful for other similar structures. BIRD50.1 is issued with these changes: The title is corrected. [Add Model Spec] is required for bus hold models Add_model_mode is illustrated Any other minor editorial correction Changes occurred or are documemented in the |* lines. The only change in BIRD50.2 is to delete the Add_model_mode subparameter in the example since BIRD48.3 deletes this subparameter. Bob Ross Interconnectix/Mentor Graphics ****************************************************************************** ****************************************************************************** BIRD ID#: 50.2 ISSUE TITLE: Add Model Bus Hold REQUESTER: Neven Orhanovic, Bob Ross, Mentor G., Arpad Muranyi, Intel DATE SUBMITTED: 4/2/98, 5/21/98, 5/29/98 DATE ACCEPTED BY IBIS OPEN FORUM: Pending ****************************************************************************** ****************************************************************************** STATEMENT OF THE ISSUE: New devices incorporate bus hold or other latching mechanisms to hold the input at a particular state using some active pullup and pulldown components. ****************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: The Bus Hold functionality is added in the new Section 6a: | Bus Hold: | |* When the Model_type subparameter under the [Model] keyword is set to |* Bus_hold, the added model describes the bus hold functionality. This |* section introduces the dynamic clamp add model functionality. | |* Existing keywords and subparameters are used to describe bus hold models. |* The [Pullup] and [Pulldown] tables both are used to define a weak internal |* buffer that is triggered switch to its opposite state. This switching |* transition is specified by a [Ramp] keyword or by the [Rising Waveform] |* and [Falling Waveform] keywords. |* |* For bus hold models, the [Add Model Spec] and V_trigger_r and V_trigger_f |* subparameters are required. | | The transition is triggered by action at the die using the [Add Model Spec] | V_trigger_r and V_trigger_f subparameters as follows: | |* If the starting voltage is below V_trigger_f, then the bus_hold model is |* set to the low state causing additional pulldown current. If the starting |* voltage is above V_trigger_r, the bus hold model is set to the high | state for additional pullup current. When the input passes though | V_trigger_f during a high-to-low transition at the die, the bus hold output |* switches to the low state. Similarly, when the input passes though |* V_trigger_r during a low-to_high transition at the die, the bus hold output |* switches to the high state. | | No additional keywords are needed for this functionality. |------------------------------------------------------------------------------ | | Complete Bus_hold Model Example: | [Model] Bus_hold_1 Model_type Bus_hold C_comp 0 0 0 | [Add Model Spec] | Subparameter typ min max | V_trigger_f 1.3 1.2 1.4 | Falling edge trigger V_trigger_r 3.1 2.6 4.6 | Rising edge trigger | [Pulldown] | -5V -100uA -80uA -120uA -1V -30uA -25uA -40uA 0V 0 0 0 1V 30uA 25uA 40uA 3V 50uA 45uA 50uA 5V 100uA 80uA 120uA 10v 120uA 90uA 150uA | [Pullup] | -5V 100uA 80uA 120uA -1V 30uA 25uA 40uA 0V 0 0 0 1V -30uA -25uA -40uA 3V -50uA -45uA -50uA 5V -100uA -80uA -120uA 10v -120uA -90uA -150uA | |**************************************************************************** | [Ramp] | typ min max dV/dt_r 2.0/0.50n 2.0/0.75n 2.0/0.35n dV/dt_f 2.0/0.50n 2.0/0.75n 2.0/0.35nn | |**************************************************************************** |============================================================================== ****************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION: A weak driver can be added using the [Add Model] keyword. BIRD50.1 adds the statement that [Add Model Spec] and its V_trigger_r and V_trigger_f subparameters are required. This is because [Add Model Spec] may not be required for other added models. BIRD50.2 deletes the Add_model_mode subparameter in the example since BIRD48.3 deletes this subparameter. ****************************************************************************** ANY OTHER BACKGROUND INFORMATION: This proposal is based on a conversation with Bob Ross, Chris Reid, and Arpad Muranyi on March 11, 1998. ****************************************************************************** From owner-ibis Fri May 29 10:59:39 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id KAA26815 for ; Fri, 29 May 1998 10:59:38 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id KAA01762; Fri, 29 May 1998 10:55:47 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id KAA06637; Fri, 29 May 1998 10:55:44 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA02736; Fri, 29 May 98 10:55:45 PDT Date: Fri, 29 May 98 10:55:45 PDT Message-Id: <9805291755.AA02736@bob> To: ibis@eda.org Subject: BIRD42.3 discussion To All: BIRD42.3 has been open for a year. We need to decide whether it is to be included in IBIS Version 3.1. BIRD42.3 is planned to be discussed at the next meeting. Refer to eda.org/pub/ibis/birds for the complete BIRD42.3 text. For background, BIRD42.3 was issued prior to IBIS Version 3.0 ratification. However, it was not ratified because there were several objections that could not be resolved. We agreed to consider it more fully for IBIS Version 3.1. Some active discussion occured when BIRD42.X was introduced and at the IBIS Summit Meetings in January, 1998 and February, 1998. BIRD42.3 introduces optional I/V tables for pullup reference and pulldown reference currents under the same conditions as existing V/T tables. Its fundamental purpose is to get a more accurate description of the power and ground currents for SSO and power integrity problems. Please call in at the June 5, 1998 meeting for a discussion on BIRD42.3. Reflector discussion is also welcome at this time. The bottom line questions are Is it needed? Will it provide improved analysis? Or is something else needed? Best Regards Bob Ross Interconnectix/Mentor Graphics From owner-ibis Fri May 29 11:07:45 1998 Received: from newsgw.mentorg.com (newsgw.mentorg.com [192.94.38.66]) by server.vhdl.org (8.8.5/8.8.3) with ESMTP id LAA27207 for ; Fri, 29 May 1998 11:07:45 -0700 (PDT) Received: from emicx.wv.mentorg.com by newsgw.mentorg.com (8.8.8/CF5.40F) id LAA02406; Fri, 29 May 1998 11:03:55 -0700 (PDT) Received: from bob by emicx.wv.mentorg.com (8.7.5/CF5.38R) id LAA06711; Fri, 29 May 1998 11:03:52 -0700 (PDT) From: bobr@emicx.mentorg.com (Bob Ross) Received: by bob (4.1/CF5.23L) id AA02751; Fri, 29 May 98 11:03:51 PDT Date: Fri, 29 May 98 11:03:51 PDT Message-Id: <9805291803.AA02751@bob> To: ibis@eda.org Subject: IBIS AGENDA 6/5/98 IBIS Open Forum Meeting Agenda for 6/5/98 Bridge Number Reservation # Passcode (916) 356-9200 4-167410 9468535 All meetings are 8:00 AM to 9:55 AM Pacific Time. When you call into the meeting, ask for the IBIS Open Forum hosted by Will Hobbs and give the Reservation Number and Passcode. 8:00 Check-In, Intros, Announcements Ross - Intros of New IBIS Participants, Meeting Quorum Ross - Membership Update and Treasurers Report Rusher - Review of Previous Meeting's Minutes (and ARs) Peters - Miscellany/Announcements All - Press & Web Page Updates Huq, All - New Models Available, Library Update Powell, All - Opens for New Issues All 8:25 Administrative and Project Discussions International/External Progress Rusher/Ross - IEC 62014-1 (IBIS Version 2.1) - pr EIAJ ED-5302 Standard for I/O Interface Model for Integrated Circuits (IMIC) - 93/67/NP IBIS and EMC Simulation Perrin - JC-16B Sessions IBIS (East) Users Group Meetings Edlund IBIS Summit Meeting at DAC Peters/Ross Editing Committee Ross/Peters BIRD44 - Interpretation of Min/Max/Weak/Strong Data Ross IBISCHK2+ (Ver 2.115) PROGRESS Flora/Rokusek Version 3.1 Parser Development Ross/Peters - Billing & Payment - Tests & Samples - IBIS Version 3.1 Spec changes/clarifications Cookbook Status Peters IBIS Model Review Committee Flora New Administrative Issues All 9:00 Technical Discussion BIRD42.3 - Modeling Current Waveforms Kumar/Ross BIRD48.3 - Add Model Orhanovic/Muranyi/Ross BIRD49.2 - Add Model Dynamic Clamps Orhanovic/Muranyi/Ross BIRD50.2 - Add Model Bus Hold Orhanovic/Muranyi/Ross BIRD46.1 - Relaxation of Some IBIS Model File Name Flora Restrictions BIRD51 - 3-state_ECL Ross Vote New Technical Issues All DAC Technical Agenda Ross/Peters 9:50 Wrap Up and Next Meetings Plans Ross 9:55 Sign Off