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


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


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

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.


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



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 lenght 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.


That's all I have at the moment.






- MM