Minutes of 8/8/2000 IBIS-X teleconference

Attending: Mike LaBonte, Bob Ross, Arpad Muranyi, Al Davis, John Angulo
Michael Cohen had intended to join us, but received the email too late.

We discussed code based models as suggested by Arpad. One possible form
for these is that of a compiled binary executable. The essence of the idea,
though, is the use of expressions to denote the relationships between
just about any operating parameters of an element.

Arpad asked why we need separate elements for static and controlled
voltage sources. This was discussed for a while. Arpad leans toward
having a small number of powerful, generic elements. Al leans toward
maintaining the familiarity of the SPICE element set. We will probably
have both. One concern is that simulators handle these elements
using different assumptions, so that, for example, a controlled
source used as a DC source may not perform the same as a purely
DC source.

We continued our review of the macromodel samples that implement existing
IBIS:

- ISSUE: Should pin be die in the "model_base" macro?
  Rpc     (pin power_clamp_ref)   I = POWER_Clamp[-V]

- The equations for elements in the consensus list have not been reviewed.
  We approved the element set, but did not thoroughly discuss the
  parameters that they accept.

- ISSUE: We need to resolve how time will be handled. For elements that
  work with time parameters (such as the trigger), is time relative to
  a local event, or is it absolute simulation time?

- ISSUE: should we use !power_clamp_ref, or something more verbose
  like exist(power_clamp_ref,) or connected(power_clamp_ref) ? This
  relates to a general debate about whether we should be using
  syntax familiar to C programmers, or something less cryptic.

- Exactly what does the "inherit" keyword do?
  It copies in all statements from the base macro.
  ISSUE: How to "disinherit" element instances?
  ISSUE: Do named instances override inherited instance of the same name?

- We decided that "correlate" should have all modes, including "typ".
  (I have added this to the consensus list).

- In statements such as '.if (Polarity == Inverting)'
  The literal "Inverting" should be in quotes.

- The ".alarm" statement should accept error message string that
  is presented to the user when the alarm is triggered.

- The ".trigger" example needs work on parentheses balancing.
  Mike suggested that the "for" value (minimum duration) should be non-zero,
  so that simulators can set appropriate breakpoints where there might ordinarily
  be none. But this is really an issue of trigger accuracy, not an
  input condition requirement. We may leave trigger accuracy up to the
  simulator.

- The output of a trigger is a time value that can be used in the expressions
  of other elements. But what is the time value before the trigger triggers?
  This also leads us back to the issue of relative vs. absolute time.
  ISSUE: Al will consider time value of a trigger before it triggers

- ISSUE: We need to clarify how the simulator receives instructions for
  wiring macromodels into the entire simulation circuit. Since the macros
  can define any number of terminals, with any node names in any order,
  there must be some convention for this.

We decided to have phone calls weekly from now on, at least until the
September summit meeting. Bob offered to allocate one hour for a summit
presentation and discussion on IBIS-X. Some ideas on this:
- Reassure people that new technology will be compatible with existing IBIS data.
- Provide a short refresher on how macro models work.
- Demo how the macro is easily enhanced for distributed die capacitances.
- Demo how a receiver model might work.

Thanks,

Mike

CONSENSUS LIST:

7/11/2000:

- 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:

- 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:

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