**************************************************************************** **************************************************************************** BIRD ID#: 142 ISSUE TITLE: Clarification of [Test Data] and [Test Load] scoping REQUESTOR: Mike LaBonte, Cisco Systems Bob Ross, Teraspeed Consulting Group DATE SUBMITTED: July 5, 2011 DATE REVISED: DATE ACCEPTED BY IBIS OPEN FORUM: September 16, 2011 **************************************************************************** **************************************************************************** STATEMENT OF THE ISSUE: The keyword hierarchy in section 3a of IBIS 5.0 shows [Test Data] to be a sub-keyword of [Model], and [Test Load] to be a sub-keyword of [Test Data]. This scoping is somewhat reinforced by the placement of the [Test Data] and [Test Load] keyword descriptions in the MODEL STATEMENT section (6). In other respects however, the [Test Load] and [Test Data] keywords appear to be designed for scoping at the top level of the IBIS hierarchy. It is more intuitive that both [Test Load] and [Test Data] would be top level keywords with unique names in a single name space. The IBIS parser in fact treats them as such, with a single name space for all [Test Load] keywords and a single name space for all [Test Data] keywords as reported in BUG 104. The IBIS specification can be changed to provide better clarity and functionality for the [Test Data] and [Test Load] keywords, simultaneously "fixing" BUG 104 by making current parser behavior correct. No change is required to the text of the descriptions for [Test Data] and [Test Load]. **************************************************************************** STATEMENT OF THE RESOLVED SPECIFICATIONS: At line 387 delete the following lines: | | |-- [Test Data] Test_data_type, Driver_model, | | | ----------- Driver_model_inv, Test_load | | | |-- [Rising Waveform Near] | | | |-- [Falling Waveform Near] | | | |-- [Rising Waveform Far] | | | |-- [Falling Waveform Far] | | | |-- [Diff Rising Waveform Near] | | | |-- [Diff Falling Waveform Near] | | | |-- [Diff Rising Waveform Far] | | | |-- [Diff Falling Waveform Far] | | | |-- [Test Load] Test_load_type, C1_near, Rs_near, | | | Ls_near, C2_near, Rp1_near, | | | Rp2_near, Td, Zo, Rp1_far, | | | Rp2_far, C2_far, Ls_far, Rs_far, | | | C1_far, V_term1, V_term2, | | | Receiver_model, | | | Receiver_model_inv, R_diff_near, | | | R_diff_far | | | At line 437 (ahead of [Define Package Model]) insert: | |-- [Test Data] Test_data_type, Driver_model, | | ----------- Driver_model_inv, Test_load | | |-- [Rising Waveform Near] | | |-- [Falling Waveform Near] | | |-- [Rising Waveform Far] | | |-- [Falling Waveform Far] | | |-- [Diff Rising Waveform Near] | | |-- [Diff Falling Waveform Near] | | |-- [Diff Rising Waveform Far] | | |-- [Diff Falling Waveform Far] | | | |-- [Test Load] Test_load_type, C1_near, Rs_near, | | Ls_near, C2_near, Rp1_near, | | Rp2_near, Td, Zo, Rp1_far, | | Rp2_far, C2_far, Ls_far, Rs_far, | | C1_far, V_term1, V_term2, | | Receiver_model, | | Receiver_model_inv, R_diff_near, | | R_diff_far | | Delete [Test Data] and [Test Load] keyword descriptions from lines 3822 to 4028. Add new Section 6d after line 7589 (asterisks indicate content changes): |============================================================================= |============================================================================= | | Section 6d | | T E S T L O A D A N D D A T A D E S C R I P T I O N | |============================================================================= |============================================================================= | | The [Test Load] and [Test Data] keywords are top-level keywords to provide | reference waveforms against which IBIS model simulation results can be | compared to determine the accuracy of the IBIS data and simulator | implementation. | |============================================================================= | Keyword: [Test Data] | Required: No | Description: Indicates the beginning of a set of Golden Waveforms and | references the conditions under which they were derived. An | IBIS file may contain any number of [Test Data] sections | representing different driver and load combinations. | Golden Waveforms are a set of waveforms simulated | using known ideal test loads. They are useful in verifying | the accuracy of behavioral simulation results against the | transistor level circuit model from which the IBIS model | parameters originated. | Sub-Params: Test_data_type, Driver_model, Driver_model_inv, Test_load | Usage Rules: The name following the [Test Data] keyword is required. It | allows a tool to select which data to analyze. | | The Test_data_type subparameter is required, and its value | must be either "Single_ended" or "Differential." The value of | Test_data_type must match the value of Test_load_type found in | the load called by Test_load. | | The Driver_model subparameter is required. Its value | specifies the "device-under-test" and must be a valid [Model] | name. Driver_model_inv is only legal if Test_data_type is | Differential. Driver_model_inv is not required but may be | used in the case in which a differential driver uses two | different models for the inverting and non-inverting pins. | | The Test_load subparameter is required and indicates which | [Test Load] was used to derive the Golden Waveforms. It must | reference a valid [Test Load] name. |----------------------------------------------------------------------------- [Test Data] Data1 Test_data_type Single_ended Driver_model Buffer1 Test_load Load1 | |============================================================================= | Keywords: [Rising Waveform Near], [Falling Waveform Near], | [Rising Waveform Far], [Falling Waveform Far], | [Diff Rising Waveform Near], [Diff Falling Waveform Near], | [Diff Rising Waveform Far], [Diff Falling Waveform Far] | Required: At least one Rising/Falling waveform is required under the | scope of the [Test Data] keyword. | Description: Describes the shape of the rising and falling Golden Waveforms | of a given driver and a given [Test Load] measured at the | driver I/O pad (near) or receiver I/O pad (far). A model | developer may use the [Rising Waveform Near/Far] and [Falling | Waveform Near/Far] keywords to document Golden Waveforms whose | purpose is to facilitate the correlation of reference | waveforms and behavioral simulations. | Usage Rules: The process, temperature, and voltage conditions under which | the Golden Waveforms are generated must be identical to those | used to generate the I-V and V-T tables. The Golden Waveforms | must be generated using unpackaged driver and receiver models. | The simulator must NOT use the Golden Waveform tables in the | construction of its internal stimulus function. | | The tables must conform to the format described under the | [Rising Waveform] and [Falling Waveform] keywords. | | Both differential and single-ended waveforms are allowed | regardless of the value of Test_data_type. If Test_data_type | is Single_ended then differential waveforms will be ignored. | If Test_data_type is Differential, a single-ended waveform | refers to the model specified by Driver_model and the | non-inverting driver output. |----------------------------------------------------------------------------- [Rising Waveform Far] | 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 Far] | 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 | |============================================================================= | Keyword: [Test Load] | Required: No | Description: Defines a generic test load network and its associated | electrical parameters for reference by Golden Waveforms | under the [Test Data] keyword. The Golden Waveform | tables correspond to a given [Test Load] which is specified | by the Test_load subparameter under the [Test Data] keyword. | Sub-Params: Test_load_type, C1_near, Rs_near, Ls_near, C2_near, Rp1_near, | Rp2_near, Td, Zo, Rp1_far, Rp2_far, C2_far, Ls_far, Rs_far, | C1_far, V_term1, V_term2, Receiver_model, Receiver_model_inv, | R_diff_near, R_diff_far. | Usage Rules: The Test_load_type subparameter is required, and its value | must be either "Single_ended" or "Differential." | | The subparameters specify the electrical parameters | associated with a fixed generic test load. The diagram | below describes the single_ended test load. | | All subparameters except Test_load_type are optional. If | omitted, series elements are shorted and shunt elements are | opened by default. | | | V_term1 | o-----------o | | | | \ \ receiver_model_name | ______ / / ______ | | | NEAR Rp1_near \ \ Rp1_far FAR | | | | |\ | / / | |\ | | | | \ | Rs_near Ls_near | _____ | Ls_far Rs_far | | \ | | | | >-|---o--/\/\--@@@@--o----o--O_____)--o----o--@@@@--/\/\--o---|-| > | | | | / | | | | Td | | | | | / | | | |/ | | C1_near | \ Zo \ | C2_far | | |/ | | |______| === === / / === === |______| | | C2_near | \ \ | C1_far | | | | / / | | | | | | V_term2 | | | | o--------------o o-----------o o--------------o | | Rp2_near Rp2_far | | GND GND | | | If the Td subparameter is present, then the Zo subparameter | must also be present. If the Td subparameter is not present, | then the simulator must remove the transmission line from | the network and short the two nodes to which it was | connected. | | V_term1 defines the termination voltage for parallel | termination resistors Rp1_near and Rp1_far. This voltage | is not related to the [Voltage Range] keyword. | If either Rp1_near or Rp1_far is used, then V_term1 must | also be used. | | V_term2 defines the termination voltage for parallel | termination resistors Rp2_near and Rp2_far. | If either Rp2_near or Rp2_far is used, then V_term2 must | also be used. | | Receiver_model is optional and indicates which, if any, | receiver is connected to the far end node. If not used, the | network defaults to no receiver. | | Receiver_model_inv is not required but may be used in the | case in which a differential receiver uses two different | models for the inverting and non-inverting pins. | Receiver_model_inv is ignored if Test_load_type is | Single-ended. | | If Test_load_type is Differential, then the test load is a | pair of the above circuits. If the R_diff_near or R_diff_far | subparameter is used, a resistor is connected between the | near or far nodes of the two circuits. If Test_load_type is | Single_ended, R_diff_near and R_diff_far are ignored. |----------------------------------------------------------------------------- [Test Load] Load1 Test_load_type Single_ended C1_near = 1p Rs_near = 10 Ls_near = 1n C2_near = 1p Rp1_near = 100 Rp2_near = 100 Td = 1ns Zo = 50 Rp1_far = 100 Rp2_far = 100 C2_far = 1p Ls_far = 1n Rs_far = 10 C1_far = 1p R_diff_far = 100 Receiver_model Input1 | variable typ min max | V_term1 1.5 1.4 1.6 V_term2 0.0 0.0 0.0 | | Example of a transmission line and receiver test load | [Test Load] Tline_rcv Td = 1n Zo = 50 Receiver_model Input1 | **************************************************************************** ANALYSIS PATH/DATA THAT LEAD TO SPECIFICATION: This proposal changes the hierarchy of [Test Data] and [Test Load] to the top-level, and the keywords are moved to a new Section 6d. The original BIRD70 (approved August 10, 2001 and rejected BIRD69.1 with some historical data) did not clearly indicate how these new keyword were positioned. In fact, there are statements that the scope is "global." However, in IBIS Version 4.0, these keywords were documented under the [Model] keyword in 4.0 the document and therefore the tree diagram showed them as scoped by the [Model Keyword], and [Test Load] scoped by the [Test Data] keyword due to some language that may have applied to the subparameter Test_load rather than to the [Test Load] keyword. Since these keywords have names as arguments, and the [Test Data] keyword names the test load and also the driver of interest, they can both be at the top-level. The [Test Load] keyword optionally names the receiver model(s). It is not clear that scoping the [Test Data] keyword under [Model] was intentional other than providing a convenient location for the validation data. It may have also been positioned there because the comparison data was model-centric, NOT component- or pin-centric. The evidence that [Test Data] and [Test Load] were not intended to be scoped hierarchically under [Model] includes: - [Test Data] has Driver_model* parameters pointing to a [Model], which conceptually might not be the [Model] keyword appear just before it. - [Test Data] has a Test_load parameter pointing to a [Test Load], which conceptually might not be the [Test Load] keyword appearing just after it. - Per the hierarchy each [Test Data] could be followed by only one [Test Load] that would actually be used. The scoping within [Model] created another problem as documented by BUG104 that [Test Load] keywords under different models could use the same name, even if the loads have different values. The hierarchy implies that each [Model] has it's own name space for [Test Data] names, such that each [Model] could have a [Test Data] keyword with the same name as the other [Test Data] keywords of other [Model] keywords. Likewise, the hierarchy implies that [Test Load] keywords with identical names could appear under each [Test Data] keyword. A new Section 6d is introduced for Test Data and Test Loads to be consistent with the revised hierarchy of the associated keywords and also to clearly separate the Testing keywords from the [Model] keyword. Existing implementations that position the test keywords after all of the other [Model] keywords (a likely situation) is still supported by the revised keyword hierarchy. The operation of ibischk5, as documented by BUG104, would be correct with the changed hierarchy since [Test Data] and [Test Load] keywords should have distinct names. So the changed hierarchy is consistent with what might have been intended and with expected operation. **************************************************************************** ANY OTHER BACKGROUND INFORMATION: The description of IBIS parser bug 104 reads as follows: The IBIS Specification requires both a Test Data name and Test Load name when using the [Test Data] keyword. The keyword hierarchy in IBIS 4.2 shows the [Test Data] keyword as a child to the parent [Model]. If two [Model] declarations in an IBIS file use the same Test Data name and/or Test Load name the IBIS Parser will flag that as an error. The IBIS Parser should not flag this as an error or warning since each [Test Data] declaration is under a different parent [Model]. The different names enable the same [Model] to be used with different [Test Loads] to generate different [Test Data] results. Note that BUG 104 requests a separate name space with each [Model] for [Test Data] and [Test Load] keywords, whereas this BIRD recommends formalizing the approach taken by the parser, which assumes a single namespace for [Test Data] and a single namespace for [Test Load]. In testing it is found that the parser accepts [Test Load] keywords after a [Model] but not preceded by a [Test Data]. ****************************************************************************