OVERVIEW The recently released ibischk4, version 4.2.1 parser has some significant improvements and changes: 1. Warnings for non-monotonic tables are now based on summation of I-V tables tests for each mode (driving, non-driving) The tests now include Submodel Dynamic_clamp tables. Individual non-monotonic tables are now reported as Notes (reduced from Warnings). The tests are applied in the same manner for all [IBIS Ver] levels from 2.0 through 4.2. - Impact: Fewer Warning messages but more information about non-montonic in a consistent manner for all levels. 2. The [Receiver Thresholds] tests have been downgraded to be more permissive and upgraded to be more comprehensive. Single-ended and differential subparameters are now permitted without any Warnings. Error reports for omitted or included information have been reduced to Warnings. The reason for these changes is that the combination of [Diff Pin], [Model Selector] along with [Receiver Thresholds] under [Model] produced some unexpected configurations that were incorrectly checked. - Impact: Models (such as DDRII with selectable on die terminators) that document thresholds according to JEDEC standards will probably report many Warning messages with ibischk4 version 4.2.1. Previously with Version 4.2.0, they might have passed with 0 Errors and 0 Warnings. These models probably have incomplete differential threshold information under certain [Diff Pin] and [Model Selector] combinations. 3. A new -caution flag is introduced to support some additional model quality checking. This test will apply for all [IBIS Ver] levels from 2.0 through 4.2 and for all file types .ibs, .pkg, and .ebd. Impact: The Quality committee in particular wants to add more tests for reasonable data. Because there might be cases where unusual entries are correct and intended, a Warning would not be appropriate. More Caution tests are expected to help the model developer catch bad data. 4. The Warning message for having an Open* Model_type (e.g, Open_drain, Open_source, etc.) and an incorrect [Pullup] or [Pulldown] table with non-zero entries is now elevated to an Error message. Impact: Files with Open* models and unexpected tables with non-zero entries will produce Errors instead of Warnings because the information is contradictory. Either the Model_type is wrong or the data is wrong. -- There are other changes, but these changes improve the ibischk4 functionality and correct some checking errors and omissions. -------------------------------------------------------------------- MORE DETAILS This release resolved seven Bug reports covering: 1. Addition of a caution flag (-caution) for special checks for suspicious data and content that are not worthy of a Warning message. This check is available for all [IBIS ver] file versions from 2.0 through 4.2 and for all file types (.ibs, .ebd, and .pkg). Currently Vmeas is checked against thresholds for certain I/O file type cases, but more tests may be added. 2. Detection of non-monotonic I-V data in a consistent manner for IBIS files for all [IBIS Ver] entries of 2.0 through 4.2 in this manner: Warnings will be issued only for combined non-montonic I-V data cases. So individual tables can be non-monotonic as long as there is no case where it the total I-V data is non-monotonic. [Submodel] I-V tables for Dynamic_clamp submodels are now included in this combined check Individual non-monotonic tables are now identified by a Note entry for any table that is non-monotonic. While these individual tables might no longer flagged as Warnings in some versions, information about non- monotonic I-V table content is now reported for all versions as a Note entry. All of these checks take into account the combinations possibilies as associated with the Model_type entry, and the [Add Submodel] modes. 3. The checks on [Receiver Thresholds] subparmeters have been corrected and made more flexable and tolerant. Some previous error messages have been reduced to a Warning and some Warnings have been removed. This change is particularly important for DDRII and above modeling. The fundamental problem is that the [Receiver Thresholds] keyword and its applications deals with both single-ended and differntial specifications, and with [Model Selector] cases to select different strengths or to select differnent on-die termations through [Model] with [Submodel] selections. Taking into account all the combinations of [Diff Pin], [Model] and [Model Selector], the previous verion 4.2.0 reported incorrectly Warnings or even Errors for some legal cases and failed to check for inclusion in some other legal cases. This change may have a major impact on some files. Files that might be reported with 0 Errors and 0 Warnings with version 4.2.0 now might show many Warnings with version 4.2.1 since undetected omissions are now reported. Specifically: Because any model can be used for a single-ended application or for a differential applicaiton, the subparameters for both single-ended specifications and differential specifications are both allowed (a message is no longer issued). In some technologies, both sets are needed. Error or Warning messages for the wrong set of [Receiver Thresholds] submodels are removed. Cases where buffers can be configured as single-ended or differential, but the associated set of thresholds are missing are reported by Warning messages. Because version 4.2.0 missed many cases, many files now will report Warnings for version 4.2.1 checking. 4. For Open_* Model_types (such as Open_drain, Open_sink and Open_source, unnecessary [Pullup] (for Open_drain/sink) or [Pulldown] (for Open_source) tables with non-zero numerical content are now reported as Errors (elevated from Warning. This was elevated to an Error because the content is technically ambigous. Either the Model_type could be incorrect and the table could be correct, or the Model_type could be correct and the table could have bad data. We could not rely on specification clarifications or EDA tools to decide this out. This is an incosistency that is upgraded to an Error. 5. Other fixes for missing entries and for a case where the parser code "crashes" by incorrect test termination.