***************************************************************************** ***************************************************************************** BIRD ID#: 150 ISSUE TITLE: IBIS-AMI New Reserved Parameters for Dependency Tables AUTHOR: Walter Katz, Todd Westerhoff, SiSoft; Adge Hawes, IBM DATE SUBMITTED: Jan. 20, 2012 DATE REVISED: DATE ACCEPTED BY IBIS OPEN FORUM: Rejected Oct. 11, 2013 ***************************************************************************** ***************************************************************************** STATEMENT OF THE ISSUE: Model developers and EDA vendors building IBIS-AMI models using the IBIS 5.0 specification have come across a number of modeling issues that are not addressed in IBIS 5.0. In order to deliver models and EDA tools that meet end-user demands for model accuracy and functionality, EDA vendors have defined "extensions" to add new capabilities to IBIS-AMI models. Unfortunately, EDA vendors have had to use proprietary (and different) syntax to add these capabilities to models, limiting model portability between different EDA tools. This BIRD proposes new syntax for the .ami control file that improves model functionality and accuracy. Including this syntax in the IBIS standard will allow creation of accurate, compliant IBIS-AMI models that are readily portable between commercial EDA simulators. Dependency Tables are Model_Specific parameters that are defined with format Table, and Usage Info. The parameter name shall end in "Dependency_Table". Dependency Tables define a relationship between one or more input parameters and one or more output parameters. Note that in this context, "input parameter" and "output parameter" refer to inputs and outputs of the relationship being defined, not to whether the parameters in question are used as inputs or outputs by the algorithmic model itself. Dependency Tables make IBIS-AMI models easier for the systems designer by allowing complex relationships between related parameters to be automatically defined as part of the model. It is also convenient to build parameter string values by substituting the string values of other parameters in sections of the string value. If a parameter string value contains a substring in the form "{}", the substring will be replaced with the string value of . ***************************************************************************** Dependency Tables Dependency Tables are used to specify relationships between different AMI parameters. This is desirable because sometimes the value to be used for an AMI parameter is dependent on the selected value of another AMI parameter. For example, consider the case of an output buffer with a user-selectable output strength setting. The strength selected by the user affects both the output's voltage swing and impedance. Assume that the output strength is controlled by a Model_Specific parameter "Tx_Strength" that has 8 discrete settings from 0 to 7, with a nominal value of 4: (Tx_Strength (Usage In)(Type Integer)(Range 4 0 7) (Description "Output buffer strength setting") ) The TX analog buffer's impedance is specified using the equivalent circuit analog model parameters. The output impedance values for each of the 8 output strength settings are: (Rs (Usage Info)(Type Float) (List 45.0 46.0 48.0 50.0 52.0 50.0 48.0 45.0) (Description "TX output impedance") ) The TX analog buffer's output swing is also specified using the equivalent circuit analog model parameters. The output voltage values for each of the 8 output strength settings are: (Voh (Usage Info)(Type Float) (List 0.40 0.42 0.44 0.46 0.48 0.50 0.52 0.54) (Description "TX output voltage") ) The model user is to be presented with a single control parameter, Tx_Strength, with the values of Rs and Voh automatically selected by the EDA tool based on the value the user specifies for Tx_Strength. Dependency Tables specify relationships between parameters to make this possible. Input parameters are placed in the left-most columns and output parameters are placed in the right-most columns of the table. The Labels row lists the Parameter names used in the table and explicitly defines whether each Parameter is used as an Input ("In") to the table, or is an output ("Out_*") whose value is derived from the table. The Labels row is required for Dependency Tables. For the example just described, one possible Dependency Table declaration is: (Tx_Strength_Dependency_Table (Usage Info) (Type Integer Float Float) (Description "Rs and Voh dependency on Tx_Strength") (Table (Labels "Tx_Strength In" "Rs Out_Match" "Voh Out_Match") (0 45.0 0.40) (1 46.0 0.42) (2 47.0 0.44) (3 50.0 0.46) (4 52.0 0.48) (5 50.0 0.50) (6 48.0 0.52) (7 45.0 0.54) ) ) This tells the EDA tool that a Tx_Strength setting of 0 corresponds to Rs = 45.0 ohms, Voh = 0.40 V, a setting of 1 corresponds to Rs = 46.0 ohms, Voh = 0.42 V, and so on. The following rules apply to the use of Dependency Tables: 1. The Parameter names used in the Dependency Table must already be declared in the .ami file, either in the Reserved_Parameter or Model_Specific sections 2. The values listed in the table for each Parameter must be a legal Format for that Parameter based, and should, but is not required, to be a legal value based on the definition of the Parameter in the .ami file. 3. Dependency Tables can only be declared in the Model_Specific section of the .ami file 4. A Dependency Table defines the relationship between one or more input parameters and one or more output parameters. 5. Two or more Dependency Tables can be linked together (i.e. output variables in one table can be used as input variables in another table) to specify complex relationships 6. Dependency Tables are evaluated in the order they are declared in the .ami file. The following elements define a Dependency Table: - Parameter name ends in Dependency_Table - Labels row (Parameter names & Input/Output declarations) - Data rows A Dependency Table declaration begins with a table name with Usage Info. The name of the Dependency Table must be unique, and by convention, ends with "Dependency_Table": Example: (My_Dependency_Table (Usage Info) (Type ...) (Description " ") (Table (Labels "" "" ...) (...) (...) ) ) The Type of a Dependency Table must have the same number of arguments as the number of arguments in the Labels row. Each Type in the list must correspond to the Type of the parameters specified in the corresponding argument of Labels. The Dependency Table can be used in Version 5.0 and Version 5.1 AMI files to document dependencies. The first row begins with the keyword "Labels" and declares the parameters defined in the table and whether they are inputs or outputs to the relationship being defined. A parameter is defined as an input to the table by adding the keyword "In" after the parameter name. A parameter is defined as an output from the table by adding one of the keywords "Out_Match", "Out_Closest", "Out_Range" or "Out_PWL" after the parameter name. Example: (Labels "Tx_Strength In" "Rs Out_Match" "Voh Out_Match")) The data rows that follow must contains lists must have the same number of items as the Labels row. The data rows contain the input parameter values that, when matched according to the defined criteria, provide the values to be used for the output parameters. Example: (Tx_Strength (Usage In)(Type String) (List "0" "1" "2" "3" "4" "5" "6" "7") (Description "Output buffer strength setting") ) (Rs (Usage Info)(Type Float) (List 45.0 46.0 48.0 50.0 52.0 50.0 48.0 45.0) (Description "TX output impedance") ) (Voh (Usage Info)(Type Float) (List 0.40 0.42 0.44 0.46 0.48 0.50 0.52 0.54) (Description "TX output voltage") ) . . . (Tx_Strength_Dependency_Table (Usage Info) (Type Integer Float Float) (Table (Labels "Tx_Strength In" "Rs Out_Match" "Voh Out_Match") (0 45.0 0.40) (1 46.0 0.42) (2 47.0 0.44) (3 50.0 0.46) (4 52.0 0.48) (5 50.0 0.50) (6 48.0 0.52) (7 45.0 0.54) ) ) The Dependency Table contains as many data rows as needed to specify all the combinations of input parameters to be tested (matched) and their corresponding output parameter values. If there is no row that matches the values in the dependent parameters then the value of the dependent parameters shall be their default value as specified in their parameter declarations. Dependency Tables support one or more columns of input parameter data and one or more columns of output parameter data. Except for the last Input column, the values of the Input Parameters must exactly match the values listed in a data row to select the Output Parameter values for that row. The last Input column in a Dependency Table (or the only Input column in the single Input case) is treated differently, however, in that piecewise linear interpolation and non-exact value matches are supported on the Input values listed in that column. The type of special treatment used when matching the last column of input parameters is specified with the Output parameter, and as such, the method of matching used can be different for each output parameter. The types of parameter matching supporting on the last input parameter column are: Out_Match Output parameter value is set to the row where the last input parameter column is an exact string match or it is a numeric match to within floating Point resolution. If no matching criteria are met, the output parameter is set to the default value as defined above. Out_Closest Output parameter value is set to the row where the last input parameter column matches closest numerically to the value of that parameter. This requires the last input parameter column to contain numeric data. If there are two equal choices, the larger value will used for selection. If it does not contain numeric data, Out_Match will be used instead. If no matching criteria are met, the output parameter is set to the default value as defined above. Out_Range Output parameter value is set to the row where the last input parameter column is less than or equal to the value of that parameter and the next numerically larger row is greater than that value. If there is not a next numerically larger row, then the output parameter value is set to the row where the last input parameter column is less than or equal to the value of that parameter. This requires the last input parameter column to contain numeric data. If it does not contain numeric data, Out_Match will be used instead. If no matching criteria are met, the output parameter is set to the default value as defined above. Out_PWL Output parameter value is set to the linear interpolated value between the row where the last input parameter column is less than or equal to the value of that parameter and the next numerically larger row is greater than that value. If there is not a next numerically larger row, then the output parameter value is set to the extrapolated value using the next numerically smaller row. If this row does not exist, then the output parameter value is set to the value where the last input parameter column is less than or equal to the value of that parameter. This requires the last input parameter column to contain numeric data. If it does not contain numeric data, Out_Match will be used instead. If no matching criteria are met, the output parameter is set to the default value as defined above. Returning to the example where the TX output buffer has a variable strength setting, but instead of 8 values, increase the number of strength selections to 71: (Tx_Strength (Usage In) (Type Integer) (Range 35 0 70) (Description "Output buffer strength setting") ) Note that Tx_Strength could have been defined as a list with 71 values. A range of Integers was used for convenience. Assume that Rs and Voh have the same minimum and maximum values as before, such that it makes sense to specify them as Format Range as well: (Rs (Usage Info) (Type Float) (Range 48.0 45.0 52.0) (Description "TX output impedance") ) (Voh (Usage Info) (Type Float) (List 0.46 0.40 0.54) (Description "TX output voltage") ) It would be possible to define a Dependency Table for all 71 possible settings of Tx_Strength, but assume that, in this case, it is just as accurate to specify the values of Rs and Voh as piecewise-linear data spaced in increments 10 units of Tx_Strength apart: (Tx_Strength_Dependency_Table (Usage Info) (Type Integer Float Float) (Table (Labels "Tx_Strength In" "Rs Out_PWL" "Voh Out_PWL") ( 0 45.0 0.40) (10 46.0 0.42) (20 47.0 0.44) (30 50.0 0.46) (40 52.0 0.48) (50 50.0 0.50) (60 48.0 0.52) (70 45.0 0.54) ) ) This tells the EDA tool that a Tx_Strength setting of 15 corresponds to Rs = 46.5 Ohms, Voh = 0.43 V, a setting of 27 corresponds to Rs = 49.1 ohms, Voh = 0.434 V, and so on. "Corner" is an internal IBIS parameter that is determined by the EDA Tool for each model instance. This is the same thing that is used by the EDA tool to determine the values of parameters, I-V and V-T tables, and External Models. In AMI models Corner, shall be treated as (Type String) and have values "Typ", "Min" and "Max", that can be used to create an input column in a Dependency Table. Its column shall have (Type String). Its allowed values are "Typ", "Min" and "Max". "Typ" represents typical operating conditions, "Min" describes slow, weak performance, and "Max" describes the fast, strong performance. (Tx_Strength_Dependency_Table (Usage Info) (Type String Float Float) (Table (Labels "Corner In" "Rs Out_Match" "Voh Out_Match") ("Min" 45.0 0.40) ("Typ" 46.0 0.42) ("Max" 47.0 0.44) ) ) "bit_time" is a predefined AMI parameter of Type Float and Usage Info that can be used to create an input column for data rate in a Dependency Table. Its Value is equal to the length of one data bit in seconds. "BAUD" is a predefined AMI parameter of Type Float and Usage Info that can be used to create an input column for data rate in a Dependency Table. Its Value is equal to 1/[bit_time]. "GBAUD" is a predefined AMI parameter of Type Float and Usage Info that can be used to create an input column for data rate in a Dependency Table. Its Value is equal to 1/([bit_time] * 1e9). "[Model]" is a predefined AMI parameter of Type String and Usage Info that can be used to create an input column to declare which IBIS [Model] each row refers to in a Dependency Table. Using string parameter values that contain one or more pairs of "{" and "}" is another method of having a string parameter value depend on other string parameter values. In the following example the string parameter My_Corner is defined to have values "nc", "wc", and "bc": (My_Corner (Corner "nc" "wc" "bc") (Usage Info) (Type String)) The string parameter Tstonefile is used in the following example: (Tstonefile (Value "{My_Corner}.s4p") (Usage Info) (Type String)) The value of Tstonefile will be "nc.s4p", "wc.s4p", "bc.s4p" for Corner "Typ", "Min", "Max" respectively. Note that {} may be nested. "abc{xxx{yyy}}" is legal. Note that Hierarchical Parameter Names are represented using "." as the hierarchical delimiter. For example, the name of the parameter (Root ...(Model_Specific(Tap(-1 (Range 0 -.4 1.) (Usage In) (Type Float))) is represented as Tap.-1 in Labels (e.g. "Tap.-2 Out_PWL"). ***************************************************************************** ANALYSIS PATH/DATA THAT LED TO SPECIFICATION The new Dependency_Table defined in this BIRD came from commercial IBIS-AMI model development efforts where new functionality was needed to meet customer expectations for model functionality, accuracy and performance. ***************************************************************************** ANY OTHER BACKGROUND INFORMATION: This BIRD is being requested by the following IBIS users and model developers, in conjunction with the authors: Cisco Systems: Upen Reddy, Doug White Ericsson: Anders Ekholm Broadcom: Yunong Gan TI: Alfred Chong, Srikanth Sundaram This BIRD is intended to supersede BIRD124. If this BIRD is approved, it is recommended that BIRD124 be rejected. This BIRD was rejected on Oct. 11, 2013, in conjunction with the acceptance of BIRD155.2.txt. *****************************************************************************