Ross: Section 6b: Figures need consistent format with either : or - Also all figures need a caption - These Changes are made: ---- Rev_2: These captions were added or these - to : changes were made: Figure 1: Partial keyword hierarchy Figure 2: Port names for I/O buffer Figure 3: Port names for series switch Figure 4: Example showing [External Circuit] ports Figure 8, 9 - to : Figure 10: Port names for true differential I/O buffer Figure 12: Reference example for [Node Declarations] keyword ---- ************************************************************** 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. 2) IBIS 3.2's re-ratification in 2005 is not mentioned in Section 1 Fixed, Renewal comment added 3) Many of the examples in the header section refer to version 4.1 instead of 4.2 Fixed, Found 2 cases via search. 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. 2) Brackets are missing around "Voltage Range" just above "Vinh, Vinl rules:" in the [Model Spec] definition. Fixed. 3) The usage rules of [Driver Schedule] use a lower-case "schedule" in the bracketed keyword. Legal, but inconsistent. Fixed. 4) Extra spaces should be removed in the Section 3a [Pin Numbers] and [Path Description] subparameter lists. Fixed, and other line feeds made consistent. Also line length shortened for some parameters. MORE WORK NEEDED ON LINEFEED CONSISTENCY 5) We state at least twice that the [Comment Char] keyword can be used "throughout" the file; I would prefer that the word "anywhere" be used, or Fixed - changed to "anywhere in" NOTE, Need to make one correction in ICM for consistency. 6) Test_data_type has an extra * in the Section 3a hierarchy Fixed. 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. - a lowercase "[pulldown]" appears in Section 6, [Pulldown], [Pullup], etc. under the paragraph starting with "From this assumption." Fixed - may be others. - each new Section should start on a new page Agree - applies to .pdf and .doc versions. - 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. - "descriptions must be described" in paragraph 2, Section 1; this is a nonsensical phrase Fixed - changed "described" to "contained" - 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. - "Modeling Data" should not be capitalized in paragraph 1, Section 2; likewise, no comma should be present after "EDA tool vendors" in that sentence Fixed. - capitalization to modeling data No Change. on comma for style consistency. Defer. - In Section 6, under the "NOTE" in "[Rising Waveform]," "Waveform" should not be capitalized Fixed. - Section 6a, under "Bus Hold", the fourth paragraph, first sentence: the second "is" should really be ", as." Fixed. - In Section 6 under "[Driver Schedule]," the example has extremely messy spacing; this should be corrected. Fixed. Changed to | Example ... Also fixed some longer lines in this section which would show up as single word line wraps in the final document. - 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. - Section 6: the paragraph just before the first diagram contains the phrase "The Vmeas subparameter is the reference voltage level that the semiconductor vendor uses for the model." I believe the word "timing" should be inserted before "reference," as the phrase is ambiguous without it. Fixed. Agree and inserted "timing" - 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. - Same section and area: we are erroneously listing the L and C units as "in terms of 'inductance/unit length' and "in terms of capacitance per unit length." Not only are the usage and grammar inconsistent, but worse, we aren't specifying the actual units of henrys and farads. We DO specify ohms for the R, as in "in terms of ohms per unit length." We should at least clean up the assumed units. --- Rev_2 - Changed in a consistent manner: capacitance/unit length --> farads/unit length inductance per unit length --> henries/unit length ohms per unit length --> ohms/unit length Left unchanged L/R/C per unit length This is the same as ICM, although ICM also uses ohms-per-unit-length There is an argument to instead change to capacitance/unit lenght, etc. but the above change is for self consistency. -- - Same error is made in the EBD section; a copy-paste was probably done here from the pkg section. No Change Yet - Need to be awake to make these changes in several areas --- Rev_2 Also fixed in above manner. --- - Section 8, under "Usage Rules," first paragraph starts with a sentence that is completely wrong, though the intent is perhaps reasonable: "A .ebd file is intended to be a stand-alone file, not associated with any .ibs file." These ARE "associated" with .ibs files, but aren't included in or referenced by them. The sentence should read, I believe, "A .ebd file is intended to be a stand-alone file, not referenced by or included within any .ibs or .pkg file." --- Rev_2 Fixed - "associated with" changed to "referenced by or included within" --- - 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 1) Section 2: missing quotation marks at the end of ver4_1.ibs and ver4_2.ibs Fixed. 2) Section 5: [Manufacturer] uses the phrase "the component's manufacture" rather than "the component's manufacturer." Fixed. 3) Section 5: [Pin Mapping] uses the phrase [Rpower] but has an opening bracket missing Fixed. 4) Section 6: under [Model Spec], Usage Rules contains the meaningless phrase "it is related to the Voltage Range settings." -- Rev_2 Phrase changed to: "For example, some subparameter values might change with the [Voltage Range] settings for each column." 5) Section 6a, just under Fig. 12, an example is given showing "Model_A," "Model_B" and so on. Unfortunately, the in-line comments refer to "A" and "B" rather than "Model_A," etc. ----------- Rev_2 Fixed: We agreed to change "Model_A" a to "A", etc. This avoided the some potential formatting issues and also is more consistent with some previous examples. Also changed [E.Circuit] to the full name [External Circuit]. --------- 6) Section 7: under RLC Matrix Notes, the phrase "1amp/sec" is used without a required space per IEEE. Also, electrical engineering notation is erroneously referred to as "metric." Spacing Fixed --- Rev_2 Fixed - changed "metric to multiplier. --- 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. 6) Section 6a, under [External Circuit], the first paragraph of "Ports" talks about [External Model] instead of [External Circuit]. Fixed. Hopefully that's it. - MM