Steffen Rochel and Ibis Committee:
In general, I agree with Will's comment that the Specification should not
be updated to comply with a more easily formulated BNF for compatibility
reasons. We are stuck with some of the Version 1.1 flexable placement
of keywords. Therefore, without really extensive listing of alternatives,
the BNF will never fully capture the IBIS standard. Also, there are
some placement restrictions and number of usage limits that may not
be fully documented in IBIS Version 1.1 and IBIS Version 2.0, but show up
with IBIS_CHK. I do not remember all the cases, but you may not use
[Date] more than once, as an example of an unspecified limitation.
The BNF appears to accurately capture the syntax of each of the keywords
and most other aspects of IBIS 2.1. It is not perfect, but should serve
as a good auxillary document. Very good parsers can be derived from it.
In practice, many of us will choose not produce a parser that is as
rigid as the specification. For example, we will correctly parse *.ibs
files that contain strings of any length, not just those with the
IBIS mandated length limits. So our model names can exceed 20 characters
and the pin numbers can exceed 5 characters. We have added some additional
non-standard capablities that are applicable to our product.
Bob Ross
Interconnectix, Inc.
Received on Thu Nov 3 19:39:43 1994
This archive was generated by hypermail 2.1.8 : Fri Jun 03 2011 - 09:52:28 PDT