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 highlight a 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 - 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. - "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. - "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. - 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. 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. - 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 - Need to be awake to make these changes in several areas - 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. No Change Yet - Need to be awake to make these changes in several areas - 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 - 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." No Change Yet - Need to be awake to make these changes in several areas - 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 No Change Yet - Also, Need to be awake to make these changes in several 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 Yet - Need to be awake to make these changes in several areas - MM