IBIS parser

John Brennan writes:

>I am generating a directory of IO circuit data where the
>directory will contain the data for a given IO(what would be
>under the [model] keyword). This data will be parsed
>into a [component] by the chip designer. I want to mark
>the IO by date, file rev, and ibis version. There are keywords for this
>at the component level, but if I put these in my IO files,
>there will be mulitple occurances of these keywords in a .ibs file
>(1 occurance for each IO). Should I...
>
>1.) leave the keywords in there since IBIS does not care if
> there are multiple occurances of these keywords.
>
>2.) Comment them out, so the parsers will not see the dates, but
> they will still show up in the .ibs file as comments.
>
>Also, is there any existing software out there that can read the
>[Pin] keyword model_name, and given directory, go get the ibis data
>for that file and append to the present file that would contain the
>[Pin] list?

I have been thinking along the same lines. I have a yacc/lex parser for
IBIS and I have been wondering how to handle libraries and also
about the
         [Disclaimer]
         [IBIS Ver]
         [File Rev]
         [Source]
         [Notes]
         [Date]
keywords. It appears that it is legal to have more than one of the above
keywords. Although the implicit assumption is that there can only be one of
each and that they are restricted to the preamble.

Having them any where facilitates having include files and having libraries of
components constructed at different dates and provided by different vendors.
I propose that we handle these keywords in the way that .OPTIONS are handled
in Spice. They remain in effect until changed.
Then a component becomes the owner of IBIS_VER, SOURCE, MOTES, DATE, FILE_REV
and DISCLAIMER data. Also John Brennan's notations can be included in
any file including those that are included.

Again to facilitate model libraries a [Model] would be treated
the same way as a .MODEL in SPICE. To facilitate a valid IBIS file could
contain only [Model] statements. In this case the maximum model name will
need to be equal to the maximum component name (40).
Currently a [Component] is terminated only by another [Component] or by an
[End]. To facilitate the different interpretation of [Model] I think that
[Component] needs to be viewed as a .SUBCKT . We need an explicit
terminator for a [Component] (e.g. [End Component]. Having an explicit
terminator is better grammatical practice anyway.

Has the IBIS community visited this before? One think that yacc forces you
to do is to explicitly state the grammar.

Michael Steer
Received on Mon Aug 1 14:55:16 1994