************************************************************** MIRMAK_1 Here's my first cut at issues in the last version of the IBIS 4.2 draft document: More serious 1) BIRD is never defined in Section 2 No Change - Defined in Version 3.0 update. 4) Section 9 mentions extraction rules for MOSFETs but does not make any allowances for having both P and N junction devices, though these are now permitted. No Change yet - need to review in detail. Defer. 5) Section 3a incorrectly suggests that On and Off are subparameters instead of keywords No Change. They are correct as subparameters for [Series Switch Groups] 6) The nonsensical phrase "single-ended differential" is used in many places in the text, but is not defined. The same is true of "true differential." The usage also conflicts with the cookbook. No Change yet - need to discuss. The Cookbook must conform to the standard. Defer. 7) We have a serious issue on the I-V [* Reference] keywords: all of these provide voltage values, but nowhere is the reference point for these voltages defined. In other words, if I define the [POWER Clamp Reference] as 5 V, is that with respect to the [GND Clamp Reference]? If I create a model with [POWER Clamp Reference] at 5 V and [GND Clamp Reference] at -5V, does this put 10 V across the buffer, or only 5 V, as the GND clamp rail is 5 V below the POWER clamp? I believe that we always assume the former is true, in which case we are actually making all [* Reference] keywords actually list voltages themselves referenced to an ideal node 0. This is very risky to include as an implication alone. We cannot make *voltages* to be the references, only *voltage rails* (i.e., nodes). Voltages are relative measurements of differences in potential between two points. In other locations, we do mention reference to "GND," a location that's separate from the GND Clamp Reference, but we don't ever define this either. I propose putting in a one-sentence description of "GND" as ideal node 0 early in the document, and ensure that the rail voltages and other voltages are appropriately referenced to this node. No Change yet - need to discuss or defer to Ver 5.0 is not a big issue. 8) Similarly to (7), we mention the Vcross_low subparameter and related subparameters are "specified with respect to 0 V." This is, simply put, garbage. We cannot reference to a voltage value, as mentioned above, but only to a rail or node. We could say "specified with respect to GND" if appropriately defined. No change yet. Defer. 9) "Other Notes" under [Model] mentions a "complete [Model] description" having [Voltage Range], I-V tables and [Ramp]. We need to be more specific for accuracy's sake, and mention this as either "minimally complete" or "complete under version 1.1." No change yet. This is minimal description and many statements are incorrect if examined in the finest detail. 10) Item 9 in Section 2 refers to sufficient points in I-V tables to ensure accurate descriptions of I-V tables. We should add a similar statement on V-t tables as well. No change yet - obvious and of no legal value - part of generic statement - "model must contain accurate data that represents the device" - which is meaningless in a standard. A likely resolution is to remove this phrase. Defer. 11) A perennial problem: reference voltage nodes/supply rails for [Ramp], [Rising Waveform] and [Falling Waveform], as well as their fixtures, are not defined (same as in 7 and 8 above). This will cause major headaches in BIRD95. An IBIS 5.0 fix should be considered, as well as a 4.2 statement that this is left up to the tools to interpret. No change yet - Too big of a rewrite with minimal benefit. Defer. Less serious 1) Single and double quotation marks are used inconsistently throughout the document. For example, [Receiver Thresholds] uses single quotes around 'typ' but the header keyword definitions use double quotes. No change - or need a complete pass and set of guidelines. Sometimes similar styles were copied for consistency from a baseline that was not consistent. 7) Units for ohms are not given in complete format in the [Package] keyword example; we have been caught on this one before. Though certainly legal, we should probably show in the example that we allow "mO" as a legitimate suffix. No change - I would use mOhm. Examples do not cover all cases since units are optional. So this is just a minor change from something that has existed since Version 1.0 - not needed. 8) The parser does NOT provide a warning if C_comp is used with C_comp_*. We should consider this, even though tools have to sort this out themselves. Good idea - need to investigate since this forces correct understanding and implementation of the syntax vs. relying on EDA tool to sort out. Defer. That's all I have at the moment. - MM ************************************************************** MIRMAK_2 Subject: More IBIS 4.2 issues... After further review, I have found some additional issues with the IBIS 4.2 document as posted: Less Serious - why do we bother with the second paragraph under Section 2? It seems redundant. No Change. This all could be rewritten, but each paragraph does seem to focus on a slightly different point. - does the copyright need to reflect GEIA? We have no legal standing as the IBIS Open Forum. No Change - When it gets approved by GEIA, the GEIA cover has the copyright. This could stand for the unofficial document. Note, we have same in ICM which is now an ANSI standard. Perhaps we should remove copyright when sent to GEIA to avoid confusion. Deal with this after ratification. - extra comma before "and this document" in paragraph 1, Section 1 No Change. I was taught that a comma before and (, and) was optional, and that is the style in the document. The (, and) does separate a different document. Defer. No Change. on comma for style consistency. Defer. - style issue, almost whole document: my grammar books direct that parenthetical phrases should not be treated as separate sentences; in other words, they should not start with capitals and should not end with periods. Further, the period of the sentence in which the parenthetical phrase appears should appear after the closing parenthesis, not before the opening one. Item 8 in Section 2 is terribly inconsistent in showing BOTH styles; additionally, a comma appears before a parenthetical, which is a major error under any style manual. No Change. I could not locate the specific issue, nor do I want to go through the whole document for this. Agree with inconsistency, but defer since this may also exist elsewhere and in ICM. More Serious - Section 5: [Series Pin Mapping], under Usage Rules, contains the phrase "the series pin for which input impedances are measured." This is totally meaningless. What was intended here? We permit series elements to be directional, but I don't recall our demanding impedance only be measured in one direction. CORRECTION - In the editing of the first version, I made a mistake in the cut and paste (and possibly in the ver4_2j.txt script and deleted the [Series Switch Groups] description (perhaps leading to the confusion about the On and Off subparameter question. No Change, need to work on the language. The example was ommitted, but the first pin was the first location for non-symetrical elements such as the [Series Current] which could be directional sensitive if it represents a diode in series. Probably revisit this in Ver 5.0. Defer. - Section 6: [Model] has a brief list of reserved words under Usage Rules; CIRCUITCALL is missing there. No Change yet. I really wanted to isolate Section 6b as a special addition. Otherwise we rewrite about 1/2 the keywords to include the Multi-lingual extension cases. - A major confusion for the Spec. E.g., [Pin] does not mention CIRCUITCALL and the item. Section 3, item 2) mentions CIRCUITCALL with forward reference to Section 6b. - In Section 7, under "[Pin Numbers]," the C definition does not specify whether a series or parallel capacitance is assumed! Referencing issues would of course be raised in the latter case. No Change Yet - Parallel is the general assumption. Defer. -- - The [End Board Description] keyword definition contains a dangerous phrase: "Optionally, a comment may be added after the [End Electrical Description] keyword to clarify which board model has ended." The example clearly shows that a comment character is used, but the sentence implies this is optional; in other words, we may be running into a potential "[End ICM Section]" issue here. I suggest either removing the phrase, as in-line comments are allowed, or adding a sentence to specify that a comment character must be used. No Change Yet - Not a big problem since the reference here was to the comment statement - as shown in the example. General rule is given elsewhere and is understood. This change would occur in many areas. - technical nit: the transmission line load used for Transit Time extraction in Section 9 is inappropriate for long-risetime interfaces, such as I2C and SMBus. This may not be too critical, as I doubt anyone would need to extract Transit Time data for such interfaces anyway No Change - Rarely used keyword not worthy of change. - MM ************************************************************** MIRMAK_3 Subject: Third Comment Set on IBIS 4.2 WIP Please, somebody stop me... :) In all seriousness, this is the third and hopefully final separate list of IBIS 4.2 WIP issues. Less Serious More Serious 1) Section 5, under [Pin], the phrase "the default packaging values must be used" appears, but what "default" references is never described. No Change Yet. Old, and I believe the reference was to [Package] which provided the "defaults" if entries were not given under [Pin] 2) Section 6, [Model] isn't technically required ("Required: Yes") -- I can legally create a POWER and GND only [Pin] list and IBIS file. No Change Yet - Check out other IBIS stuff. You are probably right but Required sometimes allows for exceptions is has implied context assumptions. 3) Section 6, under [Model] C_comp is erroneously described as "die capacitance" rather than "buffer capacitance" (I know this is a frequency complaint of mine) No Change. Have to see the impact. This could be used in many documents and locations. 4) Section 6b, under OVERVIEW, we erroneously state that [Ramp] can be replaced. No Change Yet. Really meant override the [Ramp] contents. This is still true, but the Ramp is retained, but its V-T information (as expressed as dV/dt is not used for simulation (only for EDA tools to estimate the separate timing simulation duration. However ... No Change for Ver 4.2. 5) Section 6b, under Figure 7, is A_gcref permitted on both sides of the [External Model]? No Change Yet. Diagram A_to_D and D_to_A can have internal nodes (A_myref) or the predefinded nodes. So the left-hand context is for the A_to_D and D_to_A. However, this is confusing and may be misleading. Still reviewing - also impact Figure 8. The context of the references in both figures are the issue. Hopefully that's it. - MM