|============================================================================= |============================================================================= | I/O Buffer Information Specification (IBIS) Version 3.2 (August 20, 1999) | | IBIS is a standard for electronic behavioral specifications of integrated | circuit input/output analog characteristics. |============================================================================= |============================================================================= | | T A B L E O F C O N T E N T S | |============================================================================= |============================================================================= | | Section 1 .... GENERAL INTRODUCTION | Section 2 .... STATEMENT OF INTENT | Section 3 .... GENERAL SYNTAX RULES AND GUIDELINES | Section 4 .... FILE HEADER INFORMATION | Section 5 .... COMPONENT DESCRIPTION | Section 6 .... MODEL STATEMENT | Section 6a ... ADD SUBMODEL DESCRIPTION | Section 7 .... PACKAGE MODELING | Section 8 .... ELECTRICAL BOARD DESCRIPTION | Section 9 .... NOTES ON DATA DERIVATION METHOD | |============================================================================= |============================================================================= | | Section 1 | | G E N E R A L I N T R O D U C T I O N | |============================================================================= |============================================================================= | | This section gives a general overview of the remainder of this document. | | Sections 2 and 3 contain general information about the IBIS versions and | the general rules and guidelines. Several progressions of IBIS documents | are referenced in Section 2 and in the discussion below. They are IBIS | Version 1.1 (ratified August, 1993), IBIS Version 2.1 (ratified as | ANSI/EIA-656 in December, 1995), and IBIS Version 3.2 (this document | ratified in August, 1999). | | The functionality of IBIS follows in Sections 4 through 8. Sections 4 | through 6 describe the format of the core functionality of IBIS Version 1.1 | and the extensions in later versions. The data in these sections are | contained in .ibs files. Section 7 describes the package model format of | IBIS Version 2.1 and a subsequent extension. Package models can be | formatted within .ibs files or can be formatted (along with the Section 4 | file header keywords) as .pkg files. Section 8 contains the Electrical | Board Description format of IBIS Version 3.2. Along with Section 4 header | information, electrical board descriptions must be described in separate | .ebd files. | | Section 9 contains some notes regarding the extraction conditions and data | requirements for IBIS files. This section focuses on implementation | conditions based on measurement or simulation for gathering the IBIS | compliant data. | |============================================================================= |============================================================================= | | Section 2 | | S T A T E M E N T O F I N T E N T | |============================================================================= |============================================================================= | | In order to enable an industry standard method to electronically transport | IBIS Modeling Data between semiconductor vendors, simulation vendors, and | end customers, this template is proposed. The intention of this template is | to specify a consistent format that can be parsed by software, allowing | simulation vendors to derive models compatible with their own products. | | One goal of this template is to represent the current state of IBIS data, | while allowing a growth path to more complex models / methods (when deemed | appropriate). This would be accomplished by a revision of the base | template, and possibly the addition of new keywords or categories. | | Another goal of this template is to ensure that it is simple enough for | semiconductor vendors and customers to use and modify, while ensuring that | it is rigid enough for simulation vendors to write reliable parsers. | | Finally, this template is meant to contain a complete description of the I/O | elements on an entire component. Consequently, several models will need to | be defined in each file, as well as a table that equates the appropriate | buffer to the correct pin and signal name. | | Version 3.2 of this electronic template was finalized by an industry-wide | group of experts representing various companies and interests. Regular | "EIA IBIS Open Forum" meetings were held to accomplish this task. | | Commitment to Backward Compatibility. Version 1.0 is the first valid IBIS | ASCII file format. It represents the minimum amount of I/O buffer | information required to create an accurate IBIS model of common CMOS and | bipolar I/O structures. Future revisions of the ASCII file will add items | considered to be "enhancements" to Version 1.0 to allow accurate modeling | of new, or other I/O buffer structures. Consequently, all future revisions | will be considered supersets of Version 1.0, allowing backward | compatibility. In addition, as modeling platforms develop support for | revisions of the IBIS ASCII template, all previous revisions of the template | must also be supported. | | Version 1.1 update. The file "ver1_1.ibs" is conceptually the same as the | 1.0 version of the IBIS ASCII format (ver1_0.ibs). However, various | comments have been added for further clarification. | | Version 2.0 update. The file "ver2_0.ibs" maintains backward compatibility | with Versions 1.0 and 1.1. All new keywords and elements added in Version | 2.0 are optional. A complete list of changes to the specification is in the | IBIS Version 2.0 Release Notes document ("ver2_0.rn"). | | Version 2.1 update. The file "ver2_1.ibs" contains clarification text | changes, corrections, and two additional waveform parameters beyond | Version 2.0. | | Version 3.0 update. The file "ver3_0.ibs" adds a number of new keywords | and functionality. A complete list of functions can be found on eda.org | under /pub/ibis/birds/birddir.txt showing the approved Buffer Issue | Resolution Documents (BIRDs) that have been approved for Version 3.0. | | Version 3.1 update. The file "ver3_1.ibs" contains a major reformatting of | the document and a simplification of the wording. It also contains some | new technical enhancements that were unresolved when Version 3.0 was | approved. | | Version 3.2 update. The file "ver3_2.ibs" adds more technical advances and | also a number of editorial changes documented in 12 BIRDs and also in | responses to public letter ballot comments. | |============================================================================= |============================================================================= | | Section 3 | | G E N E R A L S Y N T A X R U L E S A N D G U I D E L I N E S | |============================================================================= |============================================================================= | | This section contains general syntax rules and guidelines for ASCII IBIS | files: | | 1) The content of the files is case sensitive, except for reserved | words and keywords. | | 2) The following words are reserved words and must not be used for | any other purposes in the document: | POWER - reserved model name, used with power supply pins, | GND - reserved model name, used with ground pins, | NC - reserved model name, used with no-connect pins, | NA - used where data not available. | | 3) To facilitate portability between operating systems, file names used in | the IBIS file must only have lower case characters. File names should | have a basename of no more than twenty characters followed by a period | ('.') , followed by a file name extension of no more than three | characters. The file name and extension must use characters from the | set (space, ' ', 0x20 is not included): | | a b c d e f g h i j k l m n o p q r s t u v w x y z | 0 1 2 3 4 5 6 7 8 9 _ ^ $ ~ ! # % & - { } ) ( @ ' ` | | The file name and extension are recommended to be lower case on | systems that support such names. | | 4) A line of the file may have at most 80 characters, followed by a line | termination sequence. The line termination sequence must be one of the | following two sequences: a linefeed character, or a carriage return | followed by linefeed character. | | 5) Anything following the comment character is ignored and considered a | comment on that line. The default "|" (pipe) character can be changed | by the keyword [Comment Char] to any other character. The [Comment Char] | keyword can be used throughout the file as desired. | | 6) Keywords must be enclosed in square brackets, [], and must start in | column 1 of the line. No space or tab is allowed immediately after the | opening bracket '[' or immediately before the closing bracket ']'. If | used, only one space (' ') or underscore ('_') character separates the | parts of a multi-word keyword. | | 7) Underscores and spaces are equivalent in keywords. Spaces are not | allowed in subparameter names. | | 8) Valid scaling factors are: | T = tera k = kilo n = nano | G = giga m = milli p = pico | M = mega u = micro f = femto | When no scaling factors are specified, the appropriate base units are | assumed. (These are volts, amperes, ohms, farads, henries, and | seconds.) The parser looks at only one alphabetic character after a | numerical entry, therefore it is enough to use only the prefixes to | scale the parameters. However, for clarity, it is allowed to use full | abbreviations for the units, (e.g., pF, nH, mA, mOhm). In addition, | scientific notation IS allowed (e.g., 1.2345e-12). | | 9) The I-V data tables should use enough data points around sharply curved | areas of the I-V curves to describe the curvature accurately. In linear | regions there is no need to define unnecessary data points. | | 10) The use of tab characters is legal, but they should be avoided as much | as possible. This is to eliminate possible complications that might | arise in situations when tab characters are automatically converted to | multiple spaces by text editing, file transferring and similar software. | In cases like that, lines might become longer than 80 characters, which | is illegal in IBIS files. | | 11) Currents are considered positive when their direction is into the | component. | | 12) All temperatures are represented in degrees Celsius. | | 13) Important supplemental information is contained in the last section, | "NOTES ON DATA DERIVATION METHOD", concerning how data values are | derived. | | 14) Only ASCII characters, as defined in ANSI Standard X3.4-1986, may be | used in an IBIS file. The use of characters with codes greater than | hexadecimal 07E is not allowed. Also, ASCII control characters | (those numerically less than hexadecimal 20) are not allowed, except | for tabs or in a line termination sequence. As mentioned in item 10 | above, the use of tab characters is discouraged. | |============================================================================= |============================================================================= | | Section 4 | | F I L E H E A D E R I N F O R M A T I O N | |============================================================================= |============================================================================= | Keyword: [IBIS Ver] | Required: Yes | Description: Specifies the IBIS template version. This keyword informs | electronic parsers of the kinds of data types that are | present in the file. | Usage Rules: [IBIS Ver] must be the first keyword in any IBIS file. It is | normally on the first line of the file, but can be preceded | by comment lines that must begin with a "|". |----------------------------------------------------------------------------- [IBIS Ver] 3.2 | Used for template variations | |============================================================================= | Keyword: [Comment Char] | Required: No | Description: Defines a new comment character to replace the default | "|" (pipe) character, if desired. | Usage Rules: The new comment character to be defined must be followed by | the underscore character and the letters "char". For example: | "|_char" redundantly redefines the comment character to be | the pipe character. The new comment character is in effect | only following the [Comment Char] keyword. The following | characters MAY be used: | | ! " # $ % & ' ( ) * , : ; < > ? @ \ ^ ` { | } ~ | | Other Notes: The [Comment Char] keyword can be used throughout the file, as | desired. |----------------------------------------------------------------------------- [Comment Char] |_char | |============================================================================= | Keyword: [File Name] | Required: Yes | Description: Specifies the name of the IBIS file. | Usage Rules: The file name must conform to the rules in paragraph 3 of | Section 3, "GENERAL SYNTAX RULES AND GUIDELINES". In | addition, the file name must use the extension ".ibs", ".pkg", | or ".ebd". The file name must be the actual name of the file. |----------------------------------------------------------------------------- [File Name] ver3_2.ibs | |============================================================================= | Keyword: [File Rev] | Required: Yes | Description: Tracks the revision level of a particular .ibs file. | Usage Rules: Revision level is set at the discretion of the engineer | defining the file. The following guidelines are recommended: | 0.x silicon and file in development | 1.x pre-silicon file data from silicon model only | 2.x file correlated to actual silicon measurements | 3.x mature product, no more changes likely |----------------------------------------------------------------------------- [File Rev] 1.0 | Used for .ibs file variations | |============================================================================= | Keywords: [Date], [Source], [Notes], [Disclaimer], [Copyright] | Required: No | Description: Optionally clarifies the file. | Usage Rules: The keyword arguments can contain blanks, and be of any | format. The [Date] keyword argument is limited to a maximum | of 40 characters, and the month should be spelled out for | clarity. | | Because IBIS model writers may consider the information in | these keywords essential to users, and sometimes legally | required, design automation tools should make this information | available. Derivative models should include this text | verbatim. Any text following the [Copyright] keyword must be | included in any derivative models verbatim. |----------------------------------------------------------------------------- [Date] August 20, 1999 | The latest file revision date | [Source] Put originator and the source of information here. For example: From silicon level SPICE model at Intel. From lab measurement at IEI. Compiled from manufacturer's data book at Quad Design, etc. | [Notes] Use this section for any special notes related to the file. | [Disclaimer] This information is for modeling purposes only, and is not guaranteed. | May vary by component | [Copyright] Copyright 1999, XYZ Corp., All Rights Reserved | |============================================================================= |============================================================================= | | Section 5 | | C O M P O N E N T D E S C R I P T I O N | |============================================================================= |============================================================================= | Keyword: [Component] | Required: Yes | Description: Marks the beginning of the IBIS description of the integrated | circuit named after the keyword. | Sub-Params: Si_location, Timing_location | Usage Rules: If the .ibs file contains data for more than one component, | each section must begin with a new [Component] keyword. The | length of the component name must not exceed 40 characters, | and blank characters are allowed. | | NOTE: Blank characters are not recommended due to usability | issues. | | Si_location and Timing_location are optional and specify where | the Signal Integrity and Timing measurements are made for the | component. Allowed values for either subparameter are 'Die' | or 'Pin'. The default location is at the 'Pin'. |----------------------------------------------------------------------------- [Component] 7403398 MC452 | Si_location Pin | Optional subparameters to give measurement Timing_location Die | location positions | |============================================================================= | Keyword: [Manufacturer] | Required: Yes | Description: Specifies the manufacturer's name of the component. | Usage Rules: The length of the manufacturer's name must not exceed 40 | characters (blank characters are allowed, e.g., Texas | Instruments). In addition, each manufacturer must use a | consistent name in all .ibs files. |----------------------------------------------------------------------------- [Manufacturer] Intel Corp. | |============================================================================= | Keyword: [Package] | Required: Yes | Description: Defines a range of values for the default packaging | resistance, inductance, and capacitance of the component pins. | Sub-Params: R_pkg, L_pkg, C_pkg | Usage Rules: The typical (typ) column must be specified. If data for the | other columns are not available, they must be noted with "NA". | Other Notes: If RLC parameters are available for individual pins, they can | be listed in columns 4-6 under keyword [Pin]. The values | listed in the [Pin] description section override the default | values defined here. Use the [Package Model] keyword for more | complex package descriptions. If defined, the [Package Model] | data overrides the values in the [Package] keyword. | Regardless, the data listed under the [Package] keyword must | still contain valid data. |----------------------------------------------------------------------------- [Package] | variable typ min max R_pkg 250.0m 225.0m 275.0m L_pkg 15.0nH 12.0nH 18.0nH C_pkg 18.0pF 15.0pF 20.0pF | |============================================================================= | Keyword: [Pin] | Required: Yes | Description: Associates the component's I/O models to its various external | pin names and signal names. | Sub-Params: signal_name, model_name, R_pin, L_pin, C_pin | Usage Rules: All pins on a component must be specified. The first column | must contain the pin name. The second column, signal_name, | gives the data book name for the signal on that pin. The | third column, model_name, maps a pin to a specific I/O buffer | model or model selector name. Each model_name must have a | corresponding model or model selector name listed in a [Model] | or [Model Selector] keyword below, unless it is a reserved | model name (POWER, GND, or NC). | | Each line must contain either three or six columns. A pin | line with three columns only associates the pin's signal and | model. Six columns can be used to override the default | package values (specified under [Package]) FOR THAT PIN ONLY. | When using six columns, the headers R_pin, L_pin, and C_pin | must be listed. If "NA" is in columns 4 through 6, the | default packaging values must be used. The headers R_pin, | L_pin, and C_pin may be listed in any order. | | Column length limits are: | [Pin] 5 characters max | model_name 20 characters max | signal_name 20 characters max | R_pin 9 characters max | L_pin 9 characters max | C_pin 9 characters max |----------------------------------------------------------------------------- [Pin] signal_name model_name R_pin L_pin C_pin | 1 RAS0# Buffer1 200.0m 5.0nH 2.0pF 2 RAS1# Buffer2 209.0m NA 2.5pF 3 EN1# Input1 NA 6.3nH NA 4 A0 3-state 5 D0 I/O1 6 RD# Input2 310.0m 3.0nH 2.0pF 7 WR# Input2 8 A1 I/O2 9 D1 I/O2 10 GND GND 297.0m 6.7nH 3.4pF 11 RDY# Input2 12 GND GND 270.0m 5.3nH 4.0pF | . | . | . 18 Vcc3 POWER 19 NC NC 20 Vcc5 POWER 226.0m NA 1.0pF | |============================================================================= | Keyword: [Package Model] | Required: No | Description: Indicates the name of the package model to be used for the | component | Usage Rules: The package model name is limited to 40 characters. Spaces | are allowed in the name. The name should include the company | name or initials to help ensure uniqueness. The simulator | will search for a matching package model name as an argument | to a [Define Package Model] keyword in the current IBIS file | first. If a match is not found, the simulator will next look | for a match in an external .pkg file. If the matching package | model is in an external .pkg file, it must be located in the | same directory as the .ibs file. The file names of .pkg files | must follow the rules for file names given in section 3, | General Syntax Rules and Guidelines. | Other Notes: Use the [Package Model] keyword within a [Component] to | indicate which package model should be used for that | component. The specification permits .ibs files to contain | [Define Package Model] keywords as well. These are described | in the "Package Modeling" section near the end of this | specification. When package model definitions occur within a | .ibs file, their scope is "local"--they are known only within | that .ibs file and no other. In addition, within that .ibs | file, they override any globally defined package models that | have the same name. |----------------------------------------------------------------------------- [Package Model] QS-SMT-cer-8-pin-pkgs | |============================================================================= | Keyword: [Pin Mapping] | Required: No | Description: Used to indicate which power and ground buses a given driver, | receiver, or terminator is connected to. | Sub-Params: pulldown_ref, pullup_ref, gnd_clamp_ref, power_clamp_ref | Usage Rules: Each power and ground bus is given a unique name that must | not exceed 15 characters. The first column contains a pin | name. Each pin name must match one of the pin names declared | previously in the [Pin] section of the IBIS file. The second | column, pulldown_ref, designates the ground bus connections | for that pin. Here the term ground bus can also mean another | power bus. The third column pullup_ref designates the power | bus connection. The fourth and fifth columns gnd_clamp_ref | and power_clamp_ref contain entries, if needed, to specify | different ground bus and power bus connections than those | previously specified. | | If the [Pin Mapping] keyword is present, then the bus | connections for EVERY pin listed in the [Pin] section must | be given. | | Each line must contain either three or five columns. Use the | NC reserved word for entries that are not needed or that | follow the conditions below: | | All entries with identical labels are assumed to be connected. | Each unique entry label must connect to at least one pin whose | model_name is POWER or GND. | | If a pin has no connection, then both the pulldown_ref and | pullup_ref subparameters for it will be NC. | | GND and POWER pin entries and buses are designated by entries | in either the pulldown_ref or pullup_ref columns. There is no | implied association to any column other than through explicit | designations in other pins. | | For any other type of pin, the pulldown_ref column contains | the power connection for the [Pulldown] table for non-ECL type | [Model]s. This is also the power connection for the [GND | Clamp] table and the [Rgnd] model unless overridden by a | specification in the gnd_clamp_ref column. | | Also, the pullup_ref column contains the power connection for | the [Pullup] table and, for ECL type models, the [Pulldown] | table. This is also the power connection for the [POWER | Clamp] table and the [Rpower] model unless overridden by a | specification in the power_clamp_ref column. | | The column length limits are: | [Pin Mapping] 5 characters max | pulldown_ref 15 characters max | pullup_ref 15 characters max | gnd_clamp_ref 15 characters max | power_clamp_ref 15 characters max | | When 5 columns are specified, the headings gnd_clamp_ref and | power_clamp_ref must be used. Otherwise, these headings can | be omitted. |----------------------------------------------------------------------------- [Pin Mapping] pulldown_ref pullup_ref gnd_clamp_ref power_clamp_ref | 1 GNDBUS1 PWRBUS1 | Signal pins and their associated 2 GNDBUS2 PWRBUS2 | ground and power connections 3 GNDBUS1 PWRBUS1 GNDCLMP PWRCLAMP 4 GNDBUS2 PWRBUS2 GNDCLMP PWRCLAMP 5 GNDBUS2 PWRBUS2 NC PWRCLAMP 6 GNDBUS2 PWRBUS2 GNDCLMP NC | Some possible clamping connections | . | are shown above for illustration | . | purposes | . 11 GNDBUS1 NC | One set of ground connections. 12 GNDBUS1 NC | NC indicates no connection to 13 GNDBUS1 NC | power bus. | . 21 GNDBUS2 NC | Second set of ground connections 22 GNDBUS2 NC 23 GNDBUS2 NC | . 31 NC PWRBUS1 | One set of power connections. 32 NC PWRBUS1 | NC indicates no connection to 33 NC PWRBUS1 | ground bus. | . 41 NC PWRBUS2 | Second set of power connections 42 NC PWRBUS2 43 NC PWRBUS2 | . 51 GNDCLMP NC | Additional power connections 52 NC PWRCLMP | for clamps | |============================================================================= | Keyword: [Diff Pin] | Required: No | Description: Associates differential pins, their differential threshold | voltages, and differential timing delays. | Sub-Params: inv_pin, vdiff, tdelay_typ, tdelay_min, tdelay_max | Usage Rules: Enter only differential pin pairs. The first column, [Diff | Pin], contains a non-inverting pin name. The second column, | inv_pin, contains the corresponding inverting pin name for | I/O output. Each pin name must match the pin names declared | previously in the [Pin] section of the IBIS file. The third | column, vdiff, contains the specified output and differential | threshold voltage between pins if the pins are Input or I/O | model types. For output only differential pins, the vdiff | entry is 0 V. The fourth, fifth, and sixth columns, | tdelay_typ, tdelay_min, and tdelay_max, contain launch delays | of the non-inverting pins relative to the inverting pins. The | values can be of either polarity. | | If a pin is a differential input pin, the differential input | threshold (vdiff) overrides and supersedes the need for Vinh | and Vinl. | | If vdiff is not defined for a pin that is defined as requiring | a Vinh by its [Model] type, vdiff is set to the default value | of 200 mV. | | Other Notes: The output pin polarity specification in the table overrides | the [Model] Polarity specification such that the pin in the | [Diff Pin] column is Non-Inverting and the pin in the inv_pin | column is Inverting. This convention enables one [Model] to | be used for both pins. | | Column length limits are: | [Diff Pin] 5 characters max | inv_pin 5 characters max | vdiff 9 characters max | tdelay_typ 9 characters max | tdelay_min 9 characters max | tdelay_max 9 characters max | | Each line must contain either four or six columns. If "NA" is | entered in the vdiff, tdelay_typ, or tdelay_min columns, its | entry is interpreted as 0 V or 0 ns. If "NA" appears in the | tdelay_max column, its value is interpreted as the tdelay_typ | value. When using six columns, the headers tdelay_min and | tdelay_max must be listed. Entries for the tdelay_min column | are based on minimum magnitudes; and tdelay_max column, | maximum magnitudes. One entry of vdiff, regardless of its | polarity, is used for difference magnitudes. |----------------------------------------------------------------------------- [Diff Pin] inv_pin vdiff tdelay_typ tdelay_min tdelay_max | 3 4 150mV -1ns 0ns -2ns | Input or I/O pair 7 8 0V 1ns NA NA | Output* pin pair 9 10 NA NA NA NA | Output* pin pair 16 15 200mV 1ns | Input or I/O pin pair 20 19 0V NA | Output* pin pair, tdelay = 0 22 21 NA NA | Output*, tdelay = 0 | * Could be Input or I/O with vdiff = 0 | |============================================================================= | Keyword: [Series Pin Mapping] | Required: No | Description: Used to associate two pins joined by a series model. | Sub-Params: pin_2, model_name, function_table_group | Usage Rules: Enter only series pin pairs. The first column, [Series Pin | Mapping], contains the series pin for which input impedances | are measured. The second column, pin_2, contains the other | connection of the series model. Each pin must match the pin | names declared previously in the [Pin] section of the IBIS | file. The third column, model_name, associates the Series or | Series_switch model for the pair of pins in the first two | columns. The fourth column, function_table_group, contains | an alphanumeric designator string to associate those sets of | Series_switch pins that are switched together. | | Each line must contain either three or four columns. When | using four columns, the header function_table_group must be | listed. | | One possible application is to model crossbar switches where | the straight through On paths are indicated by one designator | and the cross over On paths are indicated by another | designator. If the model referenced is a Series model, then | the function_table_group entry is omitted. | | Column length limits are: | [Series Pin Mapping] 5 characters max | pin_2 5 characters max | model_name 20 characters max | function_table_group 20 characters max | | Other Notes: If the model_name is for a non-symmetrical series model, | then the order of the pins is important. The [Series Pin | Mapping] and pin_2 entries must be in the columns that | correspond with Pin 1 and Pin 2 of the referenced model. | | This mapping covers only the series paths between pins. The | package parasitics and any other elements such as additional | capacitance or clamping circuitry are defined by the | model_name that is referenced in the [Pin] keyword. The | model_names under the [Pin] keyword that are also referenced | by the [Series Pin Mapping] keyword may include any legal | model or reserved model except for Series and Series_switch | models. Normally the pins will reference a [Model] whose | Model_type is 'Terminator'. For example, a Series_switch | model may contain Terminator models on EACH of the pins to | describe both the capacitance on each pin and some clamping | circuitry that may exist on each pin. In a similar manner, | Input, I/O or Output models may exist on each pin of a Series | model that is serving as a differential termination. |----------------------------------------------------------------------------- [Series Pin Mapping] pin_2 model_name function_table_group | 2 3 CBTSeries 1 | Four independent groups 5 6 CBTSeries 2 9 8 CBTSeries 3 12 11 CBTSeries 4 | 22 23 CBTSeries 5 | Straight through path 25 26 CBTSeries 5 22 26 CBTSeries 6 | Cross over path 25 23 CBTSeries 6 | 32 33 Fixed_series | No group needed | |============================================================================= | Keyword: [Series Switch Groups] | Required: No | Description: Used to define allowable switching combinations of series | switches described using the names of the groups in the | [Series Pin Mapping] keyword function_table_group column | Sub-Params: On, Off | Usage Rules: Each state line contains an allowable configuration. A | typical state line will start with 'On' followed by all of the | on-state group names or an 'Off' followed by all of the | off-state group names. Only one of 'On' or 'Off' is required | since the undefined states are presumed to be opposite of the | explicitly defined states. The state line is terminated with | the slash '/', even if it extends over several lines to fit | within the 80 character column width restriction. | | The group names in the function_table_group are used to | associate switches whose switching action is synchronized by | a common control function. The first line defines the assumed | (default) state of the set of series switches. Other sets of | states are listed and can be selected through a user interface | or through automatic control. | |----------------------------------------------------------------------------- [Series Switch Groups] | Function Group States On 1 2 3 4 / | Default setting is all switched On. | Off 1 2 3 4 / | All Off setting. On 1 / | Other possible combinations below. On 2 / On 3 / On 4 / On 1 2 / On 1 3 / On 1 4 / On 2 3 / On 2 4 / On 3 4 / On 1 2 3 / On 1 2 4 / On 1 3 4 / On 2 3 4 / | Off 4 / | The last four lines above could have been replaced | Off 3 / | with these four lines with the same meaning. | Off 2 / | Off 1 / | On 5 / | Crossbar switch straight through connection On 6 / | Crossbar cross over connection Off 5 6 / | Crossbar open switches | |============================================================================= | Keyword: [Model Selector] | Required: No. | Description: Used to pick a [Model] from a list of [Model]s for a pin which | uses a programmable buffer. | Usage Rules: A programmable buffer must have an individual [Model] section | for each one of its modes used in the .ibs file. The names of | these [Model]s must be unique and can be listed under the | [Model Selector] keyword and/or pin list. The name of the | [Model Selector] keyword must match the corresponding model | name listed under the [Pin] or [Series Pin Mapping] keyword | and must not contain more than 20 characters. A .ibs file | must contain enough [Model Selector] keywords to cover all of | the model selector names specified under the [Pin] and [Series | Pin Mapping] keywords. | | The section under the [Model Selector] keyword must have two | fields. The two fields must be separated by at least one | white space. The first field lists the [Model] name (up to 20 | characters long). The second field contains a short | description of the [Model] shown in the first field. The | contents and format of this description is not standardized, | however it shall be limited in length so that none of the | descriptions exceed the 80-character length of the line that | it started on. The purpose of the descriptions is to aid the | user of the simulator tool in making intelligent buffer mode | selections and it can be used by the simulator tool in a user | interface dialog box as the basis of an interactive buffer | selection mechanism. | | The first entry under the [Model Selector] keyword shall be | considered the default by the simulator tool for all those | pins which call this [Model Selector]. | | The operation of this selection mechanism implies that a group | of pins which use the same programmable buffer (i.e. model | selector name) will be switched together from one [Model] to | another. Therefore, if two groups of pins, for example an | address bus and a data bus, use the same programmable buffer, | and the user must have the capability to configure them | independently, one can use two [Model Selector] keywords with | unique names and the same list of [Model] keywords; however, | the usage of the [Model Selector] is not limited to these | examples. Many other combinations are possible. |----------------------------------------------------------------------------- | [Pin] signal_name model_name R_pin L_pin C_pin | 1 RAS0# Progbuffer1 200.0m 5.0nH 2.0pF 2 EN1# Input1 NA 6.3nH NA 3 A0 3-state 4 D0 Progbuffer2 5 D1 Progbuffer2 320.0m 3.1nH 2.2pF 6 D2 Progbuffer2 7 RD# Input2 310.0m 3.0nH 2.0pF | . | . | . 18 Vcc3 POWER | | [Model Selector] Progbuffer1 | OUT_2 2 mA buffer without slew rate control OUT_4 4 mA buffer without slew rate control OUT_6 6 mA buffer without slew rate control OUT_4S 4 mA buffer with slew rate control OUT_6S 6 mA buffer with slew rate control | [Model Selector] Progbuffer2 | OUT_2 2 mA buffer without slew rate control OUT_6 6 mA buffer without slew rate control OUT_6S 6 mA buffer with slew rate control OUT_8S 8 mA buffer with slew rate control OUT_10S 10 mA buffer with slew rate control | |============================================================================= |============================================================================= | | Section 6 | | M O D E L S T A T E M E N T | |============================================================================= |============================================================================= | 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 | model name must match the one that is listed under a [Pin], | [Model Selector] 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], [Model Selector] and [Series Pin | Mapping] keywords, except for those model names that use | reserved words (POWER, GND and NC). | | 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 be 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, | Vref, 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 | |============================================================================= | Keyword: [Model Spec] | Required: No | Sub-Params: Vinh, Vinl, Vinh+, Vinh-, Vinl+, Vinl-, S_overshoot_high, | S_overshoot_low, D_overshoot_high, D_overshoot_low, | D_overshoot_time, Pulse_high, Pulse_low, Pulse_time, Vmeas | Description: The [Model Spec] keyword defines four columns under which | specification subparameters are defined. | | The following subparameters are defined: | Vinh Input voltage threshold high | Vinl Input voltage threshold low | Vinh+ Hysteresis threshold high max Vt+ | Vinh- Hysteresis threshold high min Vt+ | Vinl+ Hysteresis threshold low max Vt- | Vinl- Hysteresis threshold low min Vt- | S_overshoot_high Static overshoot high voltage | S_overshoot_low Static overshoot low voltage | D_overshoot_high Dynamic overshoot high voltage | D_overshoot_low Dynamic overshoot low voltage | D_overshoot_time Dynamic overshoot time | Pulse_high Pulse immunity high voltage | Pulse_low Pulse immunity low voltage | Pulse_time Pulse immunity time | Vmeas Measurement voltage for timing measurements | | Usage Rules: [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 must be placed on | a single line and must be separated by at least one white | space. All four columns are required under the [Model Spec] | keyword. However, data is required only in the typical | column. If minimum and/or maximum values are not available, | the reserved word "NA" must be used indicating the typical | value by default. | | The minimum and maximum values are used for specifications | subparameter values that may track the min and max operation | conditions of the [Model]. Usually it is related to the | Voltage Range settings. | | Unless noted below, no subparameter requires having present | any other subparameter. | | Vinh, Vinl rules: | | The threshold subparameter lines provide additional min and | max column values, if needed. The typ column values are still | required and would be expected to override the Vinh and Vinl | subparameter values specified elsewhere. Note: the syntax | rule that require inserting Vinh and Vinl under models remains | unchanged even if the values are defined under the [Model | Spec] keyword. | | Vinh+, Vinh-, Vinl+, Vinl- rules: | | The four hysteresis subparmeters (used for Schmitt trigger | inputs for defining two thresholds for the rising edges and | two thresholds for falling edges) must all be defined before | independent input thresholds for rising and falling edges of | the hysteresis threshold rules become effective. Otherwise | the standard threshold subparameters remain in effect. The | hysteresis thresholds shall be at the Vinh+ and Vinh- values | for a low-to-high transition, and at the Vinl+ and Vinl- | values for a high-to-low transition. | | | | | Receiver Voltage with Hysteresis Thresholds | | | | | | Rising Edge Falling Edge | | Switching Region oo o Switching Region | | | o oo ooooooooo | | | V o o | | Vinh+ - - - - - - - - - - x o | | Vinh- - - - - - - - - - x o | | | o o | | | o o | | | o oV | Vinl+ - - - - - - - o - - - - - - - - - - - - - - - - - x | Vinl- - - - - - - - o - - - - - - - - - - - - - - - - - x | | o o | | o o | |oooooo-----------------------------------------------------oooooooo | | Time --> | | S_overshoot_high, S_overshoot_low rules: | | The static overshoot subparameters provide the DC voltage | values for which the model is no longer guaranteed to function | correctly. Typically these are voltages that would cause the | physical component to be destroyed. | | D_overshoot_high, D_overshoot_low, D_overshoot_time rules: | | The dynamic overshoot values provide a time window during | which the overshoot may exceed the static overshoot limits | but be below the dynamic overshoot limits. D_overshoot_time | is required for dynamic overshoot testing. In addition, if | D_overshoot_high is specified, then S_overshoot_high is | necessary for testing beyond the static limit. Similarly, if | D_overshoot_low is specified, then S_overshoot_low is | necessary for testing beyond the static limit. | | | | | Receiver Voltage with Static and Dynamic Overshoot Limits | | | | | | D_overshoot_time ->| |<- | | | | | D_overshoot_high - - - - - - -+ - - -+ | | | oo | Passes - Does Not Exceed Bounds | | |o o | | S_overshoot_high - - - - - - -x o +- - - - - - - - - - - - - - - - - - - | | o o ooooooooo | | o o o | | o o | | o o | | o o | | o o | | o o | | o o Fails - | | o o Exceeds Bounds | | o o | | | | | o o V V V | |oooooo-------------------------------------------o---------o---oooo | S_overshoot_low - - - - - - - - - - - - - - - - - - - - - x +x x x - - | | |o x x | | | o o| | D_overshoot_low - - - - - - - - - - - - - - - - - - - - - + -x x-+ | | | x | | D_overshoot_time ->| |<- | | Time --> | | Pulse_high, Pulse_low, Pulse_time rules: | | The pulse immunity values provide a time window during which | a rising pulse may exceed the nearest threshold value but | be below the pulse voltage value and still not cause the | input to switch. Pulse_time is required for pulse immunity | testing. A rising response is tested only if Pulse_high is | specified. Similarly, a falling response is tested only if | Pulse_low is specified. The rising response may exceed the | Vinl value, but remain below the Pulse_high value. | | Similarly, the falling response may drop below the Vinh value, | but remain above the Pulse_low value. In either case the | input is regarded as immune to switching if the responses | are within these extended windows. If the hysteresis | thresholds are defined, then the rising response shall use | Vinh- as the reference voltage, and the falling response shall | use Vinl+ as the reference voltage. | | | | | Receiver Voltage with Pulse Immunity Thresholds | | | | | | Switching No Switching | | | | | | | oo o | Switching | | | o oo ooooooooo | | | | | o o | | | | V o o V oooV | Vinh - - - - - - - - - - x - - - - - - - - - - - - - x o + -x | | Pulse_time ->| o |<- |ooo | o | Pulse_high - - - - - + o - + Pulse_low - + - - + o | | |o | Pulse_time ->| |<- o | Vinl - - - - - - - - x + - - - - - - - - - - - - - - - - - - x | | o o | | o o | | o o | |oooooo------------------------------------------------------------o | | Time --> | | Vmeas rules: | | The Vmeas values under the [Model Spec] keyword override the | Vmeas entry elsewhere. |----------------------------------------------------------------------------- [Model Spec] | Subparameter typ min max | | Thresholds | Vinh 3.5 3.15 3.85 | 70% of Vcc Vinl 1.5 1.35 1.65 | 30% of Vcc | | Vinh 3.835 3.335 4.335 | Offset from Vcc | Vinl 3.525 3.025 4.025 | for PECL | | Hysteresis | Vinh+ 2.0 NA NA | Overrides the Vinh- 1.6 NA NA | thresholds Vinl+ 1.1 NA NA Vinl- 0.6 NA NA | All 4 are required | | Overshoot | S_overshoot_high 5.5 5.0 6.0 | Static overshoot S_overshoot_low -0.5 NA NA D_overshoot_high 6.0 5.5 6.5 | Dynamic overshoot D_overshoot_low -1.0 -1.0 -1.0 | requires | | D_overshoot_time D_overshoot_time 20n 20n 20n | & static overshoot | | Pulse Immunity | Pulse_high 3V NA NA | Pulse immunity Pulse_low 0 NA NA | requires Pulse_time 3n NA NA | Pulse_time | | Timing Thresholds | Vmeas 3.68 3.18 4.68 | A 5 volt PECL | | example | |============================================================================= | Keyword: [Add Submodel] | Required: No | Description: References a submodel to be added to an existing model. | Usage Rules: The [Add Submodel] keyword is invoked within a model to add | the functionality that is contained in the submodel or list of | submodels in each line that follows. The first column | contains the submodel name. The second column contains a | submodel mode under which the submodel is used. | | If the top-level model type is one of the I/O or 3-state | models, the submodel mode may be Driving, Non-Driving, or All. | For example, if the submodel mode is Non-Driving, then the | submodel is used only in the high-Z state of a 3-state model. | Set the submodel mode to All if the submodel is to be used for | all modes of operation. | | The submodel mode cannot conflict with the top-level model | type. For example, if the top-level model type is an Open or | Output type, the submodel mode cannot be set to Non-Driving. | Similarly, if the top-level model type is Input, the submodel | mode cannot be set to Driving. | | The [Add Submodel] keyword is not defined for Series or | Series_switch model types. | | Refer to the Add Submodel Description section in this document | for the descriptions of available submodels. | |----------------------------------------------------------------------------- [Add Submodel] | Submodel_name Mode Bus_Hold_1 Non-Driving | Adds the electrical characteristics of | [Submodel] Bus_Hold_1 for receiver or | high-Z mode only Dynamic_clamp_1 All | Adds the Dynmanic_clamp_1 model for | all modes of operation | |============================================================================= | Keyword: [Driver Schedule] | Required: No | Description: Describes the relative model switching sequence for referenced | models to produce a multi-staged driver. | Usage Rules: The [Driver schedule] keyword establishes a hierarchical order | between models and should be placed under the [Model] which | acts as the top-level model. The scheduled models are then | referenced from the top-level model by the [Driver Schedule] | keyword. | | When a multi-staged buffer is modeled using the [Driver | Schedule] keyword, all of its stages (including the first | stage, or normal driver) have to be modeled as scheduled | models. | | If there is support for this feature in a simulator, the | [Driver Schedule] keyword will cause it to use the | [Pulldown], [Pulldown Reference], [Pullup], [Pullup | Reference], [Voltage Range], [Ramp], [Rising Waveform] and | [Falling Waveform] keywords from the scheduled models | instead of the top-level model, according to the timing | relationships described in the [Driver Schedule] keyword. | Consequently, the keywords in the above list will be ignored | in the top-level model. Also, all other keywords not shown | in the above list will be ignored in the scheduled model(s). | | However, both the top-level and the scheduled model(s) have | to be complete models, i.e. all of the required keywords | must be present and follow the syntactical rules. | | For backwards compatibility reasons and for simulators which | do not support multi-staged switching, the keywords in the | above list can be used in the top-level [Model] to describe | the overall characteristics of the buffer as if it was a | composite model. It is not guaranteed, however, that such a | top-level model will yield the same simulation results as a | full multi-stage model. It is recommended that a "golden | waveform" for the device consisting of a [Rising Waveform] | table and a [Falling Waveform] table be supplied in the | top-level model to serve as a reference for validation. | | Even though some of the keywords are ignored in the | scheduled model, it may still make sense in some cases to | supply correct data with them. One such situation would | arise when a [Model] is used both as a regular top-level | model as well as a scheduled model. | | The [Driver Schedule] table consists of five columns. The | first column contains the model names of other models that | exists in the .ibs file. The remaining four columns describe | delays: Rise_on_dly, Rise_off_dly, Fall_on_dly, and | Fall_off_dly. The t=0 time of each delay is the event when | the simulator's internal pulse initiates a rising or falling | transition. All specified delay values must be equal to or | greater than 0. There are only five valid combinations in | which these delay values can be defined: | | 1) Rise_on_dly with Fall_on_dly | 2) Rise_off_dly with Fall_off_dly | 3) Rise_on_dly with Rise_off_dly | 4) Fall_on_dly with Fall_off_dly | 5) All four delays defined | (be careful about correct sequencing) | | The four delay parameters have the meaning as described | below. (Note that this description applies to buffer types | which have both pullup and pulldown structures. For those | buffer types which have only a pullup or pulldown structure, | the description for the missing structure can be omitted.) | | Rise_on_dly is the amount of time that elapses from the | internal simulator pulse initiating a RISING edge to the | t=0 time of the waveform or ramp that turns the I-V table of | the PULLUP device ON, and the t=0 time of the waveform or | ramp that turns the I-V table of the PULLDOWN device OFF (if | they were not already turned ON and OFF, respectively, by | another event). | | Rise_off_dly is the amount of time that elapses from the | internal simulator pulse initiating a RISING edge to the | t=0 time of the waveform or ramp that turns the I-V table of | the PULLUP device OFF, and the t=0 time of the waveform or | ramp that turns the I-V table of the PULLDOWN device ON (if | they were not already turned ON and OFF, respectively, by | another event). | | Fall_on_dly is the amount of time that elapses from the | internal simulator pulse initiating a FALLING edge to the | t=0 time of the waveform or ramp that turns the I-V table of | the PULLDOWN device ON, and the t=0 time of the waveform or | ramp that turns the I-V table of the PULLUP device OFF (if | they were not already turned ON and OFF, respectively, by | another event). | | Fall_off_dly is the amount of time that elapses from the | internal simulator pulse initiating a FALLING edge to the | t=0 time of the waveform or ramp that turns the I-V table of | the PULLDOWN device OFF, and the t=0 time of the waveform or | ramp that turns the I-V table of the PULLUP device ON (if | they were not already turned ON and OFF, respectively, by | another event). | | Note that some timing combinations may only be possible if | the two halves of a complementary buffer are modeled | separately as two open_* models. | | Use 'NA' when no delay value is applicable. For each | scheduled model the transition sequence must be complete, | i.e., the scheduled model must return to its initial state. | | No [Driver Schedule] table may reference a model which | itself has within it a [Driver Schedule] keyword. | | Other Notes: The added models typically consist of Open_sink (Open_drain) | or Open_source models to provide sequentially increased drive | strengths. The added drive may be removed within the same | transition for a momentary boost or during the opposite | transition. | | The syntax also allows for reducing the drive strength. | | Note that the Rise_on_dly, Rise_off_dly, Fall_on_dly, | Fall_off_dly parameters are single value parameters, so | typical, minimum and maximum conditions cannot be described | with them directly. In order to account for those effects, | one can refer to the fastest waveform table with the delay | number and then insert an appropriate amount of horizontal | lead in section in those waveforms which need more delay. | | Notice that the C_comp parameter of a multi-stage buffer is | defined in the top-level model. The value of C_comp | therefore includes the total capacitance of the entire | buffer, including all of its stages. Since the rising and | falling waveform measurements include the effects of | C_comp, each of these waveforms must be generated with the | total C_comp present, even if the various stages of the | buffer are characterized individually. | | Note: In a future release, the [Driver Schedule] keyword may | be replaced by a newer method of specification that is | consistent with some other planned extensions. However, the | [Driver Schedule] syntax will continue to be supported. |----------------------------------------------------------------------------- [Driver Schedule] | Model_name Rise_on_dly Rise_off_dly Fall_on_dly Fall_off_dly MODEL_OUT 0.0ns NA 0.0ns NA | | Examples of added multi-staged transitions M_O_SOURCE1 0.5ns NA 0.5ns NA | low (high-Z) to high high to low (high-Z) M_O_SOURCE2 0.5n 1.5n NA NA | low to high to low low (high-Z) M_O_DRAIN1 1.0n NA 1.5n NA | low to high (high-Z) high (high-Z) to low M_O_DRAIN2 NA NA 1.5n 2.0n | high (high-Z) high to low to high | |============================================================================= | Keyword: [Temperature Range] | Required: Yes, if other than the preferred 0, 50, 100 degree Celsius | range | Description: Defines the temperature range over which the model is to | operate. | Usage Rules: List the actual die temperatures (not percentages) in the typ, | min, max format. "NA" is allowed for min and max only. | Other Notes: The [Temperature Range] keyword also describes the temperature | range over which the various I-V tables and ramp rates were | derived. |----------------------------------------------------------------------------- | variable typ min max [Temperature Range] 27.0 -50 130.0 | |============================================================================= | Keyword: [Voltage Range] | Required: Yes, if [Pullup Reference], [Pulldown Reference], [POWER | Clamp Reference], and [GND Clamp Reference] are not present | Description: Defines the power supply voltage tolerance over which the | model is intended to operate. It also specifies the default | voltage rail to which the [Pullup] and [POWER Clamp] I-V data | is referenced. | Usage Rules: Provide actual voltages (not percentages) in the typ, min, max | format. "NA" is allowed for the min and max values only. | Other Notes: If the [Voltage Range] keyword is not present, then all four | of the keywords described below must be present: [Pullup | Reference], [Pulldown Reference], [POWER Clamp Reference], | and [GND Clamp Reference]. If the [Voltage Range] is present, | the other keywords are optional and may or may not be used as | required. It is legal (although redundant) for an optional | keyword to specify the same voltage as specified by the | [Voltage Range] keyword. |----------------------------------------------------------------------------- | variable typ min max [Voltage Range] 5.0V 4.5V 5.5V | |============================================================================= | Keyword: [Pullup Reference] | Required: Yes, if the [Voltage Range] keyword is not present. | Description: Defines a voltage rail other than that defined by the [Voltage | Range] keyword as the reference voltage for the [Pullup] I-V | data. | Usage Rules: Provide actual voltages (not percentages) in the typ, min, max | format. "NA" is allowed for the min and max values only. | Other Notes: This keyword, if present, also defines the voltage range over | which the typ, min, and max dV/dt_r values are derived. |----------------------------------------------------------------------------- | variable typ min max [Pullup Reference] 5.0V 4.5V 5.5V | |============================================================================= | Keyword: [Pulldown Reference] | Required: Yes, if the [Voltage Range] keyword is not present. | Description: Defines a power supply rail other than 0 V as the reference | voltage for the [Pulldown] I-V data. If this keyword is not | present, the voltage data points in the [Pulldown] I-V table | are referenced to 0 V. | Usage Rules: Provide actual voltages (not percentages) in the typ, min, max | format. "NA" is allowed for the min and max values only. | Other Notes: This keyword, if present, also defines the voltage range over | which the typ, min, and max dV/dt_f values are derived. |----------------------------------------------------------------------------- | variable typ min max [Pulldown Reference] 0V 0V 0V | |============================================================================= | Keyword: [POWER Clamp Reference] | Required: Yes, if the [Voltage Range] keyword is not present. | Description: Defines a voltage rail other than that defined by the [Voltage | Range] keyword as the reference voltage for the [POWER Clamp] | I-V data. | Usage Rules: Provide actual voltages (not percentages) in the typ, min, | max format. "NA" is allowed for the min and max values only. | Other Notes: Refer to the "Other Notes" section of the [GND Clamp | Reference] keyword. |----------------------------------------------------------------------------- | variable typ min max [POWER Clamp Reference] 5.0V 4.5V 5.5V | |============================================================================= | Keyword: [GND Clamp Reference] | Required: Yes, if the [Voltage Range] keyword is not present. | Description: Defines a power supply rail other than 0 V as the reference | voltage for the [GND Clamp] I-V data. If this keyword is not | present, the voltage data points in the [GND Clamp] I-V table | are referenced to 0 V. | Usage Rules: Provide actual voltages (not percentages) in the typ, min, max | format. "NA" is allowed for the min and max values only. | Other Notes: Power Supplies: It is intended that standard TTL and CMOS | models be specified using only the [Voltage Range] keyword. | However, in cases where the output characteristics of a model | depend on more than a single supply and ground, or a [Pullup], | [Pulldown], [POWER Clamp], or [GND Clamp] table is referenced | to something other than the default supplies, use the | additional 'reference' keywords. |----------------------------------------------------------------------------- | variable typ min max [GND Clamp Reference] 0V 0V 0V | |============================================================================= | Keywords: [TTgnd], [TTpower] | Required: No | Description: These keywords specify the transit time parameters used to | estimate the transit time capacitances or develop transit time | capacitance tables for the [GND Clamp] and [POWER Clamp] | tables. | Usage Rules: For each of these keywords, the three columns hold the transit | values corresponding to the typical, minimum and maximum [GND | Clamp] or [POWER Clamp] tables, respectively. The entries for | TT(typ), TT(min), and TT(max) must be placed on a single line | and must be separated by at least one white space. All three | columns are required under these keywords. 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 TT(typ) value by default. | Other Notes: The transit time capacitance is added to C_comp. It is in a | Spice reference model as Ct = TT * d(Id)/d(Vd) where | d(Id)/d(Vd) defines the DC conductance at the incremental DC | operating point of the diode, and TT is the transit time. | This expression does not include any internal series | resistance. Such a resistance is assumed to be negligible in | practice. Assume that the internal diode current (Id) - | voltage (Vd) relationship is Id = Is * (exp(q(Vd)/kT) - 1) | where Is is the saturation current, q is electron charge, k is | Boltzmann's constant, and T is temperature in degrees Kelvin. | Then d(Id)/d(Vd) is approximately (q/kT) * Id when the diode | is conducting, and zero otherwise. This yields the | simplification Ct = TT * (q/kT) * Id. The Id is found from | the [GND Clamp] and [POWER Clamp] operating points, and the | corresponding TTgnd or TTpower is used to calculate the Ct | value. If the [Temperature Range] keyword is not defined, | then use the default "typ" temperature for all Ct | calculations. | | The effective TT parameter values are intended to APPROXIMATE | the effects. They may be different from the values found in | the Spice diode equations. Refer to the NOTES ON DATA | DERIVATION METHOD for extracting the effective values. |----------------------------------------------------------------------------- | variable TT(typ) TT(min) TT(max) [TTgnd] 10n 12n 9n [TTpower] 12n NA NA | |============================================================================= | Keywords: [Pulldown], [Pullup], [GND Clamp], [POWER Clamp] | Required: Yes, if they exist in the model | Description: The data points under these keywords define the I-V tables of | the pulldown and pullup structures of an output buffer and the | I-V tables of the clamping diodes connected to the GND and the | POWER pins, respectively. Currents are considered positive | when their direction is into the component. | Usage Rules: In each of these sections, the first column contains the | voltage value, and the three remaining columns hold the | typical, minimum, and maximum current values. The four | entries, Voltage, I(typ), I(min), and I(max) must be placed on | a single line and must be separated by at least one white | space. | | All four columns are required under these keywords. However, | data is only required in the typical column. If minimum | and/or maximum current values are not available, the reserved | word "NA" must be used. "NA" can be used for currents in the | typical column, but numeric values MUST be specified for the | first and last voltage points on any I-V table. Each I-V | table must have at least 2, but not more than 100, voltage | points. | | Other Notes: The I-V table of the [Pullup] and the [POWER Clamp] structures | are 'Vcc relative', meaning that the voltage values are | referenced to the Vcc pin. (Note: Under these keywords, all | references to 'Vcc' refer to the voltage rail defined by the | [Voltage Range], [Pullup Reference], or [POWER Clamp | Reference] keywords, as appropriate.) The voltages in the | data tables are derived from the equation: Vtable = Vcc - | Voutput. | | Therefore, for a 5 V model, -5 V in the table actually | means 5 V above Vcc, which is +10 V with respect to ground; | and 10 V means 10 V below Vcc, which is -5 V with respect to | ground. Vcc-relative data is necessary to model a pullup | structure properly, since the output current of a pullup | structure depends on the voltage between the output and Vcc | pins and not the voltage between the output and ground pins. | Note that the [GND Clamp] I-V table can include quiescent | input currents, or the currents of a 3-stated output, if so | desired. | | When tabulating data for ECL models, the data in the | [Pulldown] table is measured with the output in the 'logic | low' state. In other words, the data in the table represents | the I-V characteristics of the output when the output is at | the most negative of its two logic levels. Likewise, the data | in the [Pullup] table is measured with the output in the | 'logic one' state and represents the I-V characteristics when | the output is at the most positive logic level. Note that in | BOTH of these cases, the data is referenced to the Vcc supply | voltage, using the equation: Vtable = Vcc - Voutput. | | Monotonicity Requirements: | | To be monotonic, the I-V table data must meet any one of the | following 8 criteria: | 1- The CURRENT axis either increases or remains constant as | the voltage axis is increased. | 2- The CURRENT axis either increases or remains constant as | the voltage axis is decreased. | 3- The CURRENT axis either decreases or remains constant as | the voltage axis is increased. | 4- The CURRENT axis either decreases or remains constant as | the voltage axis is decreased. | | 5- The VOLTAGE axis either increases or remains constant as | the current axis is increased. | 6- The VOLTAGE axis either increases or remains constant as | the current axis is decreased. | 7- The VOLTAGE axis either decreases or remains constant as | the current axis is increased. | 8- The VOLTAGE axis either decreases or remains constant as | the current axis is decreased. | | An IBIS syntax checking program shall test for non-monotonic | data and provide a maximum of one warning per I-V table if | non-monotonic data is found. For example: | | "Warning: Line 300, Pulldown I-V table for model DC040403 | is non-monotonic! Most simulators will filter this data | to remove the non-monotonic data." | | It is also recognized that the data may be monotonic if | currents from both the output stage and the clamp diode are | added together as most simulators do. To limit the complexity | of the IBIS Version 2.x and Version 3.x syntax checking | programs, such programs will conduct monotonicity testing only | on one I-V table at a time. | | It is assumed that the simulator sums the clamp tables | together with the appropriate [Pullup] or [Pulldown] table | when a buffer is driving high or low, respectively. From this | assumption and the nature of 3-statable buffers, it follows | that the data in the clamping table sections are handled as | constantly present tables and the [Pullup] and [Pulldown] | tables are used only when needed in the simulation. | | The clamp tables of an Input or I/O buffer can be measured | directly with a curve tracer, with the I/O buffer 3-stated. | However, sweeping enabled buffers results in tables that are | the sum of the clamping tables and the output structures. | Based on the assumption outlined above, the [Pullup] and | [Pulldown] tables of an IBIS model must represent the | difference of the 3-stated and the enabled buffer's tables. | (Note that the resulting difference table can demonstrate a | non-monotonic shape.) This requirement enables the simulator | to sum the tables, without the danger of double counting, and | arrive at an accurate model in both the 3-stated and enabled | conditions. | | Since in the case of a non 3-statable buffer, this difference | table cannot be generated through lab measurements (because | the clamping tables cannot be measured alone), the [Pullup] | and [Pulldown] tables of an IBIS model can contain the sum of | the clamping characteristics and the output structure. In | this case, the clamping tables must contain all zeroes, or the | keywords must be omitted. |----------------------------------------------------------------------------- [Pulldown] | Voltage I(typ) I(min) I(max) | -5.0V -40.0m -34.0m -45.0m -4.0V -39.0m -33.0m -43.0m | . | . 0.0V 0.0m 0.0m 0.0m | . | . 5.0V 40.0m 34.0m 45.0m 10.0V 45.0m 40.0m 49.0m | [Pullup] | Note: Vtable = Vcc - Voutput | | Voltage I(typ) I(min) I(max) | -5.0V 32.0m 30.0m 35.0m -4.0V 31.0m 29.0m 33.0m | . | . 0.0V 0.0m 0.0m 0.0m | . | . 5.0V -32.0m -30.0m -35.0m 10.0V -38.0m -35.0m -40.0m | [GND Clamp] | | Voltage I(typ) I(min) I(max) | -5.0V -3900.0m -3800.0m -4000.0m -0.7V -80.0m -75.0m -85.0m -0.6V -22.0m -20.0m -25.0m -0.5V -2.4m -2.0m -2.9m -0.4V 0.0m 0.0m 0.0m 5.0V 0.0m 0.0m 0.0m | [POWER Clamp] | Note: Vtable = Vcc - Voutput | | Voltage I(typ) I(min) I(max) | -5.0V 4450.0m NA NA -0.7V 95.0m NA NA -0.6V 23.0m NA NA -0.5V 2.4m NA NA -0.4V 0.0m NA NA 0.0V 0.0m NA NA | |============================================================================= | Keywords: [Rgnd], [Rpower], [Rac], [Cac] | Required: Yes, if they exist in the model | Description: The data for these keywords define the resistance values of | Rgnd and Rpower connected to GND and the POWER pins, | respectively, and the resistance and capacitance values for an | AC terminator. | Usage Rules: For each of these keywords, the three columns hold the | typical, minimum, and maximum resistance values. The three | entries for R(typ), R(min), and R(max), or the three entries | for C(typ), C(min), and C(max) must be placed on a single line | and must be separated by at least one white space. All three | columns are required under these keywords. However, data is | only required in the typical column. If minimum and/or | maximum values are not available, the reserved word "NA" must | be used indicating the R(typ) or C(typ) value by default. | Other Notes: It should be noted that [Rpower] is connected to 'Vcc' and | [Rgnd] is connected to 'GND'. However, [GND Clamp Reference] | voltages, if defined, apply to [Rgnd]. [POWER Clamp | Reference] voltages, if defined, apply to [Rpower]. Either or | both [Rgnd] and [Rpower] may be defined and may coexist with | [GND Clamp] and [POWER Clamp] tables. If the terminator | consists of a series R and C (often referred to as either an | AC or RC terminator), then both [Rac] and [Cac] are required. | When [Rgnd], [Rpower], or [Rac] and [Cac] are specified, the | Model_type must be Terminator. | | |<-------------TERMINATOR Model--------------->| | | [Voltage Range] or | [POWER Clamp Reference] | o | | | POWER_ o---o---o | clamp | | | |--o--| \ | | | / | | I-V | \ Rpower [Package] Keyword | | | / Subparameters * | |--o--| | |<----------------->| | | | | | | PIN | o-----o-------o-----o-----/\/\/\--@@@@@@---o--o | | |GND_ | | R_pkg L_pkg | | | |clamp | | | | | |--o--| | | | | | | | \ | | | | | I-V | /Rgnd | | | | | | \ \ | | | |--o--| / / Rac | | | | | \ | | | o---o---o / | | | | | | | C_comp === o === Cac C_pkg === | | GND or | | | | [GND Clamp | | | | Reference] | | | o-------------------o----------------------o | | | o | GND | | * Note: More advanced package parameters are available | within this standard, including more detailed | power and ground net descriptions. |----------------------------------------------------------------------------- | variable R(typ) R(min) R(max) [Rgnd] 330ohm 300ohm 360ohm | Parallel Terminator [Rpower] 220ohm 200ohm NA | [Rac] 30ohm NA NA | | variable C(typ) C(min) C(max) | AC terminator [Cac] 50pF NA NA | |============================================================================= | Keywords: [On], [Off] | Required: Yes, both [On] and [Off] for Series_switch Model_types only | Description: The 'On' state electrical models are positioned under [On]. | The 'Off' state electrical models are positioned under [Off]. | Usage Rules: These keywords are only valid for Series_switch Model_types. | Only keywords associated with Series_switch electrical models | are permitted under [On] or [Off]. The Series electrical | models describe the path for one state only and do not use | the [On] and [Off] keywords. | | In Series_switch models, [On] or [Off] must be positioned | before any of the [R Series], [L Series], Rl Series], | [C Series], [Lc Series], [Rc Series], [Series Current], | and [Series MOSFET] keywords. There is no provision for | any of these keywords to be defined once, but to apply to | both states. |----------------------------------------------------------------------------- [On] | ... On state keywords such as [R Series], [Series Current], [Series MOSFET] [Off] | ... Off state keywords such as [R Series], [Series Current] | |============================================================================= | Keywords: [R Series], [L Series], [Rl Series], [C Series]. [Lc Series], | [Rc Series] | Required: Yes, if they exist in the model | Description: The data for these keywords allow the definition of Series or | Series_switch R, L or C paths. | Usage Rules: For each of these keywords, the three columns hold the | typical, minimum, and maximum resistance values. The three | entries must be placed on a single line and must be separated | by at least one white space. All three columns are required | under these keywords. However, data is only required in the | typical column. If minimum and/or maximum values are not | available, the reserved word "NA" must be used. | Other Notes: This series RLC model is defined to allow IBIS to model simple | passive models and/or parasitics. | | These keywords are valid only for Series or Series_switch | Model_types. | | The model is: | | R Series | +---/\/\/\/\---------------------+ | | | | Pin 1 | L Series Rl Series | Pin 2 | <---+---@@@@@@@@---/\/\/\/\----------+---> | | | | | | | | | +---| |---@@@@@@@@@---/\/\/\/\---+ | | | Lc Series Rc Series | C Series | | [Rl Series] shall be defined only if [L Series] exists. | [Rl Series] is 0 ohms if it is not defined in the path. | | [Rc Series] and [Lc Series] shall be defined only if | [C Series] exists. [Rc Series] is 0 ohms if it is not | defined in the path. [Lc Series] is 0 henries if it is | not defined in the path. | | C_comp values are ignored for these keywords. |----------------------------------------------------------------------------- | variable R(typ) R(min) R(max) [R Series] 8ohm 6ohm 12ohm | | variable L(typ) L(min) L(max) [L Series] 5nH NA NA | variable R(typ) R(min) R(max) [Rl Series] 4ohm NA NA | | variable C(typ) C(min) C(max) | The other elements [C Series] 50pF NA NA | are 0 impedance | |============================================================================= | Keyword: [Series Current] | Required: Yes, if they exist in the model | Description: The data points under this keyword define the I-V tables for | voltages measured at Pin 1 with respect to Pin 2. Currents | are considered positive if they flow into Pin 1. Pins 1 and | 2 are listed under the [Series Pin Mapping] keyword under | columns [Series Pin Mapping] and pin_2, respectively. | Usage Rules: The first column contains the voltage value, and the remaining | columns hold the typical, minimum, and maximum current values. | The four entries, Voltage, I(typ), I(min), and I(max) must be | placed on a single line and must be separated by at least one | white space. | | All four columns are required under these keywords. However, | data is only required in the typical column. If minimum | and/or maximum current values are not available, the reserved | word "NA" must be used. "NA" can be used for currents in the | typical column, but numeric values MUST be specified for the | first and last voltage points on any I-V table. Each I-V | table must have at least 2, but not more than 100, voltage | points. | | Other Notes: There is no monotonicity requirement. However the model | supplier should realize that it may not be possible to derive | a behavioral model from non-monotonic data. | | These keywords are valid only for Series or Series_switch | Model_types. | | The model is: | | Table Current | ------> | + Table Voltage - | Pin 1 |---------| Pin 2 | <---+ +---> | |---------| | | C_comp values are ignored for [Series Current] models. |----------------------------------------------------------------------------- [Series Current] | Voltage I(typ) I(min) I(max) -5.0V -3900.0m -3800.0m -4000.0m -0.7V -80.0m -75.0m -85.0m -0.6V -22.0m -20.0m -25.0m -0.5V -2.4m -2.0m -2.9m -0.4V 0.0m 0.0m 0.0m 5.0V 0.0m 0.0m 0.0m | |============================================================================= | Keyword: [Series MOSFET] | Required: Yes, for series MOSFET switches | Description: The data points under this keyword define the I-V tables for | voltages measured at Pin 2 for a given Vds setting. Currents | are considered positive if they flow into Pin 1. Pins 1 and | 2 are listed under the [Series Pin Mapping] keyword under | [Series Pin Mapping] and pin_2 columns, respectively. | Sub-Params: Vds | Usage Rules: The first column contains the voltage value, and the three | remaining columns hold the typical, minimum, and maximum | current values. The four entries, Voltage, I(typ), I(min), | and I(max) must be placed on a single line and must be | separated by at least one white space. | | All four columns are required under these keywords. However, | data is only required in the typical column. If minimum | and/or maximum current values are not available, the reserved | word "NA" must be used. "NA" can be used for currents in the | typical column, but numeric values MUST be specified for the | first and last voltage points on any I-V table. Each I-V | table must have at least 2, but not more than 100, voltage | points. | | Other Notes: There is no monotonicity requirement. However the model | supplier should realize that it may not be possible to derive | a behavioral model from non-monotonic data. | | The model is: | | Table Current | -------> | + Vds - | Pin 1 Pin 2 | <---| |---> + | d |_____| - s | --+-- Vgs Vs | | g + | - | | Vg = [Voltage Range] = Vcc | Vgs = Table Voltage = Vtable = Vcc - Vs | Ids = Table Current for a given Vcc and Vds | | Internal logic that is generally referenced to the power rail | is used to set the MOSFET switch to its 'On' state. Thus the | [Voltage Range] settings provide the assumed gate voltages. | If the [POWER Clamp Reference] exists, it overrides the | [Voltage Range] value. The table entries are actually the Vgs | values referenced to the power rail. The polarity conventions | are identical with those used for other tables that are | referenced to power rails. Thus the voltage column can be | viewed as a table defining the source voltages Vs according to | the convention: Vtable = Vcc - Vs. | | If the switch is used in an application such as interfacing | between 3.3 V and 5.0 V logic, the Vcc may be biased at a | voltage (such as 4.3 V) that is different from a power rail | voltage (such as 5.0 V) used to create the model. Just | readjust the [Voltage Range] entries (or [POWER Clamp | Reference] entries). | | One fundamental assumption in the MOSFET switch model is that | it operates in a symmetrical manner. The tables and | expressions are given assuming that Vd >= Vs. If Vd < Vs, | then apply the same relationships under the assumption that | the source and drain nodes are interchanged. A consequence of | this assumption is that the Vds subparameter is constrained to | values Vds > 0. It is assumed that with Vds = 0 the currents | will be 0 mA. A further consequence of this assumption that | would be embedded in the analysis process is that the voltage | table is based on the side of the model with the lowest | voltage (and that side is defined as the source). Thus the | analysis must allow current to flow in both directions, as | would occur due to reflections when the switch is connected in | series with an unterminated transmission line. | | The model data is used to create an On state relationship | between the actual drain to source current, ids, and the | actual drain to source voltage, vds: | | ids = f(vds). | | This functional relationship depends on the actual source | voltage Vs and can be expressed in terms of the corresponding | table currents associated with Vs (and expressed as a function | of Vgs). | | If only one [Series MOSFET] table is supplied (as a first | order approximation), the functional relationship is assumed | to be linearly related to the table drain to source current, | Ids, for the given Vds subparameter value and located at the | existing gate to source voltage value Vgs. This table current | is denoted as Ids(Vgs, Vds). The functional relationship | becomes: | | ids = Ids(Vgs, Vds) * vds / Vds. | | More than one [Series MOSFET] table is permitted, but it is | simulator dependent how the data will be used. Each | successive [Series MOSFET] table must have a different | subparameter value for Vds. The number of tables must not | exceed 100. | | C_comp values are ignored for [Series MOSFET] models. |----------------------------------------------------------------------------- [On] [Series MOSFET] Vds = 1.0 | Voltage I(typ) I(min) I(max) 5.0V 257.9m 153.3m 399.5m | Defines the Ids current as a 4.0V 203.0m 119.4m 317.3m | function of Vgs, for Vds = 1.0 3.0V 129.8m 74.7m 205.6m 2.0V 31.2m 16.6m 51.0m 1.0V 52.7p 46.7p 56.7p 0.0V 0.0p 0.0p 0.0p | |============================================================================= | Keyword: [Ramp] | Required: Yes, except for inputs, terminators, Series and Series_switch | model types. | Description: Defines the rise and fall times of a buffer. The ramp rate | does not include packaging but does include the effects of the | C_comp parameter. | Sub-Params: dV/dt_r, dV/dt_f, R_load | Usage Rules: The rise and fall time is defined as the time it takes the | output to go from 20% to 80% of its final value. The ramp | rate is defined as: | | dV 20% to 80% voltage swing | -- = ---------------------------------------- | dt Time it takes to swing the above voltage | | The ramp rate must be specified as an explicit fraction and | must not be reduced. The [Ramp] values can use "NA" for the | min and max values only. The R_load subparameter is optional | if the default 50 ohm load is used. The R_load subparameter | is required if a non-standard load is used. |----------------------------------------------------------------------------- [Ramp] | variable typ min max dV/dt_r 2.20/1.06n 1.92/1.28n 2.49/650p dV/dt_f 2.46/1.21n 2.21/1.54n 2.70/770p R_load = 300ohms | |============================================================================= | Keywords: [Rising Waveform], [Falling Waveform] | Required: No | Description: Describes the shape of the rising and falling edge waveforms | of a driver. | Sub-Params: R_fixture, V_fixture, V_fixture_min, V_fixture_max, C_fixture, | L_fixture, R_dut, L_dut, C_dut | Usage Rules: Each [Rising Waveform] and [Falling Waveform] keyword | introduces a table of time vs. voltage points that describe | the shape of an output waveform. These time/voltage points | are taken under the conditions specified in the | R/L/C/V_fixture and R/L/C_dut subparameters. 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. 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 need | not be '0'. Time values must increase as one parses down the | table. The waveform table can contain a maximum of 100 data | points. A maximum of 100 waveform tables are allowed per | model. Note that for backward compatibility, the existing | [Ramp] keyword is still required. The data in the waveform | table is taken with the effects of the C_comp parameter | included. | | A waveform table must include the entire waveform; i.e., the | first entry (or entries) in a voltage column must be the DC | voltage of the output before switching and the last entry (or | entries) of the column must be the final DC value of the | output after switching. 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. | | A [Model] specification can contain more than one rising edge | or falling edge waveform table. However, each new table must | begin with the appropriate keyword and subparameter list as | shown below. If more than one rising or falling edge waveform | table is present, then the data in each of the respective | tables must be time correlated. In other words, the rising | (falling) edge data in each of the rising (falling) edge | waveform tables must be entered with respect to a common | reference point on the input stimulus waveform. | | The 'fixture' subparameters specify the loading conditions | under which the waveform is taken. The R_dut, C_dut, and | L_dut subparameters are analogous to the package parameters | R_pkg, C_pkg, and L_pkg and are used if the waveform includes | the effects of pin inductance/capacitance. The diagram below | shows the interconnection of these elements. | | PACKAGE | TEST FIXTURE | _________ | | | DUT | L_dut R_dut | L_fixture R_fixture | | die |---@@@@@--/\/\/\--o-----|--@@@@---o---/\/\/\----- V_fixture | |_________| | | | | | | | | | | | | C_dut === | === C_fixture | | | | | | | | | GND | GND | | NOTE: The use of L_dut, R_dut, and C_dut is strongly | discouraged in developing Waveform data from simulation | models. Some simulators may ignore these parameters because | they may introduce numerical time constant artifacts. | | Only the R_fixture and V_fixture subparameters are required, | the rest of the subparameters are optional. If a subparameter | is not used, its value defaults to zero. The subparameters | must appear in the text after the keyword and before the first | row of the waveform table. | | V_fixture defines the voltage for typ, min, and max supply | conditions. However, when the fixture voltage is related to | the power supply voltages, then the subparameters | V_fixture_min and V_fixture_max can be used to further specify | the fixture voltage for min and max supply voltages. | | NOTE: Test fixtures with R_fixture and V_fixture, | V_fixture_min, and V_fixture_max only are strongly encouraged | because they provide the BEST set of data needed to produce | the best model for simulation. C_fixture and L_fixture can be | used to produce waveforms which describe the typical test case | setups for reference. | | NOTE: In most cases two [Rising Waveform] tables and two | [Falling Waveform] tables will be necessary for accurate | modeling. | | All tables assume that the die capacitance is included. | Potential numerical problems associated with processing the | data using the effective C_comp for effective die capacitance | may be handled differently among simulators. |----------------------------------------------------------------------------- [Rising Waveform] R_fixture = 50 V_fixture = 0.0 | C_fixture = 50p | These are shown, but are generally not recommended | L_fixture = 2n | C_dut = 7p | R_dut = 1m | L_dut = 1n | Time V(typ) V(min) V(max) 0.0000s 25.2100mV 15.2200mV 43.5700mV 0.2000ns 2.3325mV -8.5090mV 23.4150mV 0.4000ns 0.1484V 15.9375mV 0.3944V 0.6000ns 0.7799V 0.2673V 1.3400V 0.8000ns 1.2960V 0.6042V 1.9490V 1.0000ns 1.6603V 0.9256V 2.4233V 1.2000ns 1.9460V 1.2050V 2.8130V 1.4000ns 2.1285V 1.3725V 3.0095V 1.6000ns 2.3415V 1.5560V 3.1265V 1.8000ns 2.5135V 1.7015V 3.1600V 2.0000ns 2.6460V 1.8085V 3.1695V | ... 10.0000ns 2.7780V 2.3600V 3.1670V | [Falling Waveform] R_fixture = 50 V_fixture = 5.5 V_fixture_min = 4.5 V_fixture_max = 5.5 | Time V(typ) V(min) V(max) 0.0000s 5.0000V 4.5000V 5.5000V 0.2000ns 4.7470V 4.4695V 4.8815V 0.4000ns 3.9030V 4.0955V 3.5355V 0.6000ns 2.7313V 3.4533V 1.7770V 0.8000ns 1.8150V 2.8570V 0.8629V 1.0000ns 1.1697V 2.3270V 0.5364V 1.2000ns 0.7539V 1.8470V 0.4524V 1.4000ns 0.5905V 1.5430V 0.4368V 1.6000ns 0.4923V 1.2290V 0.4266V 1.8000ns 0.4639V 0.9906V 0.4207V 2.0000ns 0.4489V 0.8349V 0.4169V | ... 10.0000ns 0.3950V 0.4935V 0.3841V | |============================================================================= |============================================================================= | | Section 6a | | A D D S U B M O D E L D E S C R I P T I O N | |============================================================================= |============================================================================= | | The [Add Submodel] keyword can be used under a top-level [Model] keyword to | to add special-purpose functionality to the existing top-level model. This | section describes the structure of the top-level model and the submodel. | | TOP-LEVEL MODEL: | | When special-purpose functional detail is needed, the top-level model can | call one or more submodels. The [Add Submodel] keyword is positioned | after the initial set of required and optional subparameters of the [Model] | keyword and among the keywords under [Model]. | | The [Add Submodel] keyword lists of name of each submodel and the permitted | mode (Driving, Non-Driving or All) under which each added submodel is used. | | SUBMODEL: | | A submodel is defined using the [Submodel] keyword. It contains a subset | of keywords and subparameters used for the [Model] keyword along with other | keywords and subparameters that are needed for the added functionality. | | The [Submodel] and [Submodel Spec] keywords are defined first since they | are used for all submodels | | The only required subparameter in [Submodel] is Submodel_type to define the | list of submodel types. No subparameters under [Model] are permitted under | the [Submodel] keyword. | | The following set of keywords that are defined under the [Model] keyword are | supported by the [Submodel] keyword: | | [Pulldown] | [Pullup] | [GND Clamp] | [POWER Clamp] | [Ramp] | [Rising Waveform] | [Falling Waveform] | | The [Voltage Range], [Pullup Reference], [Pulldown Reference], [GND Clamp | Reference], and [POWER Clamp Reference] keywords are not permitted. The | voltage settings are inherited from the top-level model. | | These additional keywords are used only for the [Submodel] are documented | in this section: | | [Submodel Spec] | [GND Pulse Table] | [POWER Pulse Table] | | The application of these keywords depends upon the Submodel_type entries | listed below: | | Dynamic_clamp | Bus_hold | | Permitted keywords that are not defined for any of these submodel types are | ignored. The rules for what set of keywords are required are found under | the Dynamic Clamp and Bus Hold headings of this section. | |============================================================================= | Keyword: [Submodel] | Required: No | Description: Used to define a submodel, and its attributes. | Sub-Params: Submodel_type | Usage Rules: Each submodel must begin with the keyword [Submodel]. The | submodel name must match the one that is listed under an | [Add Submodel] keyword and must not contain more than 20 | characters. A .ibs file must contain enough [Submodel] | keywords to cover all of the model names specified under the | [Add Submodel] keyword. | | Submodel_type subparameter is required and must be one of the | following: | | Dynamic_clamp, Bus_hold | | The C_comp subparameter is not permitted under the [Submodel] | keyword. The total effective die capacitance including the | submodel contributions are provided in the top-level model. | | Other Notes: The following list of keywords that are defined under the | [Model] keyword can be used under [Submodel]: [Pulldown], | [Pullup], [GND Clamp], [POWER Clamp], [Ramp], [Rising | Waveform], and [Falling Waveform]. | | The following list of additional keywords can be used: | [Submodel Spec], [GND Pulse Table], and [POWER Pulse Table]. |----------------------------------------------------------------------------- [Submodel] Dynamic_clamp1 Submodel_type Dynamic_clamp | |============================================================================= | Keyword: [Submodel Spec] | Required: No | Description: The [Submodel Spec] keyword defines four columns under which | specification and information subparameters are defined for | submodels. | Sub-Params: V_trigger_r, V_trigger_f, Off_delay | Usage Rules: The [Submodel Spec] is to be used only with submodels. | | The following subparameters are used: | V_trigger_r Rising edge trigger voltage | V_trigger_f Falling edge trigger voltage | Off_delay Turn-off delay from V_trigger_r or | V_trigger_f | | 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. All four columns are required under the [Submodel | Spec] keyword. However, data is required only in the typical | column. If minimum and/or maximum values are not available, | the reserved word "NA" must be used to indicate the typical | value by default. | | The values in the minimum and maximum columns usually | correspond to the values in the same columns for the inherited | top-level voltage range or reference voltages in the top-level | model. The V_trigger_r and V_trigger_f subparameters should | hold values in the minimum and maximum columns that correspond | to the voltage range or reference voltages of the top-level | model. The Off_delay subparameter, however, is an exception | to this rule because in some cases it may be completely or | or partially independent from supply voltages and/or | manufacturing process variations. Therefore the minimum and | maximum entries for the Off_delay subparameter should be | ordered simply by their magnitude. | | Unless noted, each [Submodel Spec] subparameter is independent | of any other subparameter. | | V_trigger_r, V_trigger_f rules: | | The voltage trigger values for the rising and falling edges | provide the starting time when an action is initiated. | | Off_delay rules: | | The functionality of the Off_delay subparameter is to provide | an additional time related mechanism to turn off circuit | elements. |----------------------------------------------------------------------------- | Dynamic Clamp Example: | [Submodel Spec] | Subparameter typ min max | V_trigger_r 3.6 2.9 4.3 | Starts power pulse table V_trigger_f 1.4 1.2 1.6 | Starts gnd pulse table | | Bus Hold Example: | [Submodel Spec] | Subparameter typ min max V_trigger_r 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 | | Bus_hold application with pullup structure triggered on and then clocked off: | [Submodel Spec] | Subparameter typ min max V_trigger_r 3.1 2.4 3.7 | Low to high transition | triggers the turn on | process of the pullup V_trigger_f -10.0 -10.0 -10.0 | Not used, so trigger | voltages are set out | of range Off_delay 5n 6n 4n | Time from rising edge | trigger at which the | pullup turned off | |============================================================================= | | Dynamic Clamp: | | When the Submodel_type subparameter under the [Submodel] keyword is set to | Dynamic_clamp, the submodel describes the dynamic clamp functionality. | | The [GND Pulse Table] and [POWER Pulse Table] keywords are defined. An | example for a complete dynamic clamp model is provided. | |============================================================================= | Keywords: [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 submodels. | 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). Note, these | voltage values are inherited from the top-level model. | | 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. 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 of | 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, the [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 [POW