Minutes of 8/29/2000 IBIS-X teleconference

Attending: Mike LaBonte, Bob Ross, Arpad Muranyi, Al Davis, John Angulo, Mike Cohen

It was announced that Al Davis has left Hyperlynx. He is now contributing
as an independent consultant.

Mike reviewed some goals for the committee, discussed at the initial IBIS
Futures meeting.  These are not necessarily the working goals of our
committee.

We discussed backward compatibility issues:
- Users must be assured that there will be a compatibility path for existing
  IBIS files.
- One issue is the baggage of writing a parser that understands new IBIS
  format as well as the existing "sloppy" format:
  - As long as the [IBIS Ver] keyword appears at the beginning of a file,
    it can be used to easily determine when to switch between 2 separate
    parsers.
  - We could also have a sloppy parser mode triggered by a keyword. This
    idea did not go over very well.
  - A translator could be used to convert existing "sloppy" files to new
    format.
    - This could be used by simulator tools that have only a rigid parser.
    - Plus, this could be used by IC vendors to post new format files.
    - CONSENSUS: We agreed that this seems like a good approach.
    - ISSUE: where will the code come from?

We reviewed Al's new "be_driver" file:
- This covers the "driver" behavioral element.
- Arpad asked if the driver can receive? The answer is "no".
- Not shown in the file; the driver has to also know about:
  - clamp curves
  - C_comp
  This is because the waveforms reflect the effects of this data.
- There was a good deal of discussion on "How does the driver work?".
  - It mainly implements the VT curve following algorithm, which is very
    complex. Also, simulator vendors have not revealed their algorithms.
  - Arpad agreed that we need to have a waveform following algorithm,
    but he suggested that that buffers might be written using a number of
    interconnected macro elements, without using the driver element. 
  - Maybe we need a control element instead of the driver. The controlled
    sources and other elements could be separate, external elements,
    receiving control signals from the control element.
  - The driver input is controlled "symbolically" by a trigger, but
    there is a terminal to enable and disable it. Mike suggested input and
    enable should work the same way.

The driver discussion got us off onto a tangent about the question of
exactly how simulators implement VT curve following.
- Bob suggested that vendors could supply macro language describing
  how their simulators handle drivers, even if the actual simulation
  is performed by native code. It is not certain that the macro language
  is sufficiently complete to do this.
- Al suggested that vendors should share their proprietary algorithms.
  Arpad asked if these algorithms are patented? No one knew of any
  related patents.
- A potential problem is that simulators may give different results
  for a model. An alternative to examining the algorithms is to
  produce a suite of certification tests with reference data.

Thanks,

Mike

CONSENSUS LIST:

7/11/2000 meeting:

- The specification will define a [File Name] field similar to current IBIS.
  Unlike current IBIS it will be optional, however.

- The following Spice-compatible elements are accepted into the macro language:
        Resistor (R)    (v = f(i,t), i = f(v,t), r = constant or f(t))
        Capacitor (C)   (q = f(v,t), c = f(v,t), c = constant or f(t))
        Inductor (L)    (flux = f(i,t), L = f(i,t), L = constant or f(t))
        VCVS (E)        (Vout = f(Vin,t))
        VCCS (G)        (Iout = f(Vin,t))
        Isource (I)     (I = constant or f(t))
        Vsource (V)     (V = constant or f(t))
        Diode (D)       (basic diode, subset of Spice parameters)
        Subckt (X)      (used for submodel, driver schedule)

7/25/2000 meeting:

- The circuit element statement format will have:
  - An element type code as the first word. The instance name is not a part
    of this word.
  - An optional instance name as the second word.
  - A list of connection names in parentheses. The parentheses are required,
    especially to allow parsers to detect the absence of an instance name.
    Other features of the element statement are TBD.

- We will have the ".correlate" control statement to identify the names of
  the operating conditions to which multiple data values for parameters
  correspond. Format details are TBD.

8/8/2000 meeting:

- The "correlate" statements will list all modes, including "typ". Originally
  only "fast" and "slow" were listed.

8/15/2000 meeting:

- The ".inherit" statement must be defined as an inline expansion that can be
  performed at read time.  The contents of the inherited macro are simply
  inserted in place of the ".inherit" statement.  This makes it easy to
  implement and to understand. A simple preprocessor may be used.

8/22/2000 meeting:

We reviewed 2 documents on the ".select" statement, sent by Al. One
documents the original ".select" which is dynamically evaluated. The
other covers an alternative form that can be statically evaluated
at parse time.
- CONSENSUS: We will use the alternate "select", which is static.

8/29/2000 meeting:

- One issue is the baggage of writing a parser that understands new IBIS
  format as well as the existing "sloppy" format:
  - A translator could be used to convert existing "sloppy" files to new
    format.
    - CONSENSUS: We agreed that this seems like a good approach.