*****************************************************************************
*****************************************************************************

BIRD ID#:	 124  
ISSUE TITLE:     IBIS-AMI New Reserved Parameters for Dependency Tables
REQUESTER: 	 Walter Katz, Mike Steinberger, Todd Westerhoff, SiSoft
DATE SUBMITTED:  October 20, 2010
DATE REVISED:    
DATE ACCEPTED BY IBIS OPEN FORUM: Rejected May 11, 2012

*****************************************************************************
*****************************************************************************

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.   

The parameters defined in this document are to be added in Section 6c of the 
IBIS 5.0 specification as new Reserved_Parameters.  

The following new keywords allow the construction of Dependency Tables in IBIS-AMI 
models.  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.
 
Dependency, Parameter, Default_Row

Note that all of the parameters defined in this BIRD may be declared in the 
Model_Specific section of the .ami file to allow the use of some legacy models.  
However, using these parameters in the Model_Specific section of the .ami file is 
considered legacy use and will likely be deprecated in IBIS versions beyond 5.1.

*****************************************************************************

The following text is added immediately before Table 1 on page 148:

| 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.
| 
| Let’s 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 table header ("Parameter") 
| 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.
| 
| For the example just described, one possible Dependency Table declaration is:
| 
| (Tx_Strength_Table 
|    (Dependency
| 	(Parameter (Usage Info)(Type String)
|            (List "Tx_Strength In" "Rs Out_Match" "Voh Out_Match"))
| 	(Row1 (List 0  45.0  0.40)(Usage Info)(Type Float))
| 	(Row2 (List 1  46.0  0.42)(Usage Info)(Type Float))
| 	(Row3 (List 2  47.0  0.44)(Usage Info)(Type Float))
| 	(Row4 (List 3  50.0  0.46)(Usage Info)(Type Float))
| 	(Row5 (List 4  52.0  0.48)(Usage Info)(Type Float))
| 	(Row6 (List 5  50.0  0.50)(Usage Info)(Type Float))
| 	(Row7 (List 6  48.0  0.52)(Usage Info)(Type Float))
| 	(Row8 (List 7  45.0  0.54)(Usage Info)(Type Float))
|    )
| )
| 
| 
| This tells the EDA tool that a Tx_Strength setting of 0 corresponds to Rs = 45.0 
| ohms, Voh = 0.40V, a setting of 1 corresponds to Rs = 46.0 ohms, Voh = 0.42V, 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 legal values for 
|    that Parameter based on its definition 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:
| 
| • Table declaration
| • Header row (Parameter names & Input/Output declarations)
| • Data rows
| 
| A Dependency Table declaration begins with a table name followed by the keyword 
| "Dependency".  The name of the Dependency Table must be unique, and by convention, 
| ends with "_Table":
| 
| Example:
| 
| (My_Table 
|    (Dependency
|       (
| 
|  
| The header row begins with the keyword "Parameter" 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:
| 
| (Parameter (Usage Info)(Type String)
|   (List "Tx_Strength In" "Rs Out_Match" "Voh Out_Match"))
| 
| The header row is always of Usage Info, Type String and Format List. The data 
| rows that follow must contains lists must have the same number of items as the 
| header 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.  
| Data rows are always specified as Usage Info and Format List.  Note that in order 
| to comply with the definition of the List format, all entries in the list must 
| have the same Type. This poses a bit of a challenge since different columns can 
| have parameters of different types (remember that the parameters used in each 
| column are defined separately in the .ami file). For example, the parameter in 
| one column may be of Type Integer, the next column of Type Float, and the next 
| column of Type String. The Type chosen for the List must therefore be one that 
| can express all of the entries in the row, and EDA tool is be responsible for 
| converting each parameter value to the correct Type as determined by the 
| respective parameter definition.
| 
| In practice, the most general solution is to always declare data rows to be of 
| Type String and surround each entry in the table with double quotes "".  The EDA 
| tool is responsible for performing any necessary Type conversion.  
| 
| 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_Table 
|    (Dependency
| 	(Parameter (Usage Info)(Type String)
|            (List "Tx_Strength In" "Rs Out_Match" "Voh Out_Match"))
| 	(Row1 (List "0"  "45.0"  "0.40")(Usage Info)(Type String))
| 	(Row2 (List "1"  "46.0"  "0.42")(Usage Info)(Type String))
| 	(Row3 (List "2"  "47.0"  "0.44")(Usage Info)(Type String))
| 	(Row4 (List "3"  "50.0"  "0.46")(Usage Info)(Type String))
| 	(Row5 (List "4"  "52.0"  "0.48")(Usage Info)(Type String))
| 	(Row6 (List "5"  "50.0"  "0.50")(Usage Info)(Type String))
| 	(Row7 (List "6"  "48.0"  "0.52")(Usage Info)(Type String))
| 	(Row8 (List "7"  ‘45.0"  "0.54")(Usage Info)(Type String))
|    )
| )
| 
|  
| If all of the parameters listed in the data row are a numeric Type (Float, 
| Tap, UI, or Integer), the row can be declared as Type Float.  
| 
| Example:
| 
| (Tx_Strength (Usage In)(Type Integer)(Range 4 0 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_Table 
|    (Dependency
| 	(Parameter (Usage Info)(Type String)
|            (List "Tx_Strength In" "Rs Out_Match" "Voh Out_Match"))
| 	(Row1 (List 0  45.0  0.40)(Usage Info)(Type Float))
| 	(Row2 (List 1  46.0  0.42)(Usage Info)(Type Float))
| 	(Row3 (List 2  47.0  0.44)(Usage Info)(Type Float))
| 	(Row4 (List 3  50.0  0.46)(Usage Info)(Type Float))
| 	(Row5 (List 4  52.0  0.48)(Usage Info)(Type Float))
| 	(Row6 (List 5  50.0  0.50)(Usage Info)(Type Float))
| 	(Row7 (List 6  48.0  0.52)(Usage Info)(Type Float))
| 	(Row8 (List 7  45.0  0.54)(Usage Info)(Type Float))
|    )
| )
| 
| 
| If all of the parameters listed in the data row are of the same Type, then 
| that Type can be used, but that’s usually not the case.
| 
| 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.  In order to comply with the rules of the .ami file 
| syntax, each data row must start with a name (Row1 ... Row8 in the above 
| example).  There are no constraints on row names, and the EDA tool, except 
| for the reserved row name "Default_Row", ignores the row names. 
| 
| A row with the name "Default_Row" may be used to define the output parameter 
| values to be used when values of the input parameters do not match any row in 
| the Dependency Table.  The values of the input parameters specified in "Default 
| Row" are ignored by the EDA tool. If no Default_Row is defined in the table 
| and there is no match, then an output parameter will be set to its default 
| value from its declaration.
| 
| Example:
| 
| (Default_Row (List "NA"  "45.0"  "0.54")(Usage Info)(Type String))
| 
| 
| Note that the Type used for the Default_Row must match the Type declared for 
| the other data rows in the table.
| 
| Dependency Tables support one or more columns of input parameter data and one 
| or more columns of output parameter data.  Generally speaking, 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 interpolation and non-exact value matches are 
| supported on the Input values listed in that column.  Limiting special 
| treatment to a single input column limits the complexity of the Dependency 
| Table. 
| 
| 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.
| 
| As an example, let’s return to the example where the TX output buffer has a 
| variable strength setting, but instead of 8 values, we’ll 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 we could have defined Tx_Strength as a list with 71 values, but 
| that’s impractical - it’s more convenient to define it as a range of Integers.
| 
| Let’s 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 let’s assume that, in this case, it’s 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_Table 
|    (Dependency
| 	(Parameter (Usage Info) (Type String)) 
|          (List "Tx_Strength In" "Rs Out_PWL" "Voh Out_PWL")
| 	)
| 	(Row1 (List  0 45.0 0.40)(Usage Info)(Type Float))
| 	(Row2 (List 10 46.0 0.42)(Usage Info)(Type Float))
| 	(Row3 (List 20 47.0 0.44)(Usage Info)(Type Float))
| 	(Row4 (List 30 50.0 0.46)(Usage Info)(Type Float))
| 	(Row5 (List 40 52.0 0.48)(Usage Info)(Type Float))
| 	(Row6 (List 50 50.0 0.50)(Usage Info)(Type Float))
| 	(Row7 (List 60 48.0 0.52)(Usage Info)(Type Float))
| 	(Row8 (List 70 45.0 0.54)(Usage Info)(Type Float))
|    )
| )
| 
| 
| This tells the EDA tool that a Tx_Strength setting of 15 corresponds to Rs = 46.5 
| ohms, Voh = 0.43V, a setting of 27 corresponds to Rs = 49.1 ohms, Voh = 0.434V, 
| and so on.
| 
| Note that the use of Out_PWL in the above table means a Default_Row declaration 
| is not needed, since the only legal values for Tx_Strength are between 0 and 70 
| inclusive, and there is no value for which the EDA tool could not interpolate 
| the values for Rs and Voh.
| 
| The syntax definition for a Dependency Table is:
| 
| dependency table:
|             (<table name>
| 			(Dependency
| 				<column header row>
| 				<table body>
| 			)
| 		)
| 
| column header row:
| 		(Parameter
| 			(Usage Info) (Type String)
| 			(List <column header list>)
| 		)
| 
| 
| column header list:  <input column header list> <output column header list>
| 
| input column header list:  <input column header> <input column header> ...
| 
| output column header list:  <output column header> <output column header> ...
| 
| input column header:   "<parameter name> In"
| 
| output column header:   "<parameter name> <output column type>"
| 
| output column type: Out_Match | Out_Closest | Out_Range | Out_PWL
| 
| table body: <table row> <table row> <table row> ...
| 
| table row:  (<row name> (List <row list>) (Usage Info) (Type <row type>))
| 
| row list: <parameter value> <parameter value> <parameter value> ...
| 
| row type: String | Float | Integer | Boolean | Tap | UI
| 
| The column header list and all of the row lists in a dependency table shall have 
| the same number of list entries.
| 
| The row type supplied for a table row shall be a type that can be converted to 
| the type of any parameter value in the row.
| 
| "[Corner]" is a predefined AMI parameter of Type String and Usage Info that can 
| be used to create an input column in a dependency table. It has a List format with 
| the allowed values "Typ", "Slow" and "Fast".
| 
| "[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.  It has 
| a Value format and 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. It has 
| a Value format and 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. It has 
| a Value format and 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. 
| 
| 
*****************************************************************************

ANALYSIS PATH/DATA THAT LED TO SPECIFICATION


The parameters 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.  The parameters 
in this BIRD were defined by SiSoft and its semiconductor partners.  These 
parameters are being contributed to IBIS to ensure IBIS-AMI model accuracy 
and portability.

*****************************************************************************

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
IBM: Adge Hawes
TI: Alfred Chong, Srikanth Sundaram

BIRDs 121 through 124 split the concepts and changes of BIRD 119 into separate
documents.

*****************************************************************************