Minutes of 9/5/2000 IBIS Futures teleconference Attending: Bob Ross, Stephen Peters, John Angulo, Al Davis, Michael Cohen, Mike LaBonte, Evgeny Wasserman As planned, we discussed presentations for the IBIS summit meeting 9/14/2000. Subcommittee info is available at http://www.mike.labonte.com/ibis/future/ Review of Mike's IBIS Futures Overview presentation: Slide: General Themes - The ".correlate" statement is actually a means of managing datasets. There can be more than just typ/min/max, and the names are arbitrary. Mike suggested having these statements in the data section, not in the macro section. - We clarified how compatibility is achieved for existing IBIS files. Standard macro definitions for existing IBIS structures are implicit, and may be omitted from IBIS data files that are based on the existing IBIS definition. Only models that require new features would require [Define Model] sections. Slide: Top Level Format - The top level file file format should be basically the same as the IBIS Connector format, although some of us have issues with the connector format. - Al feels that putting certain data inside the opening tag brackets of a section is too unfamiliar to gain acceptance. The existing IBIS format is not *that* inconsistent that a complete change is needed. - Al prefers a parser compatibility mode over a format translator for the purpose of making new software compatible with old IBIS formats. Slide: Separation of Circuit Topology and Data - Bob suggested minor corrections to the AC terminator example used to show the separation of data from circuit topology. We decided to keep this simple example instead of showing a buffer model that implements multiple die capacitance or edge-sensitive die capacitance. Slide: Macro Language - Lengthy discussion of what macro element capabilities are required in a first release of the spec. Stephen did a fine job representing Arpad's position that more is better (see the minutes of any prior meeting). - This slide is moved to the end of the presentation. Slide: Nodal Interconnect - We discussed the applicability of the IBIS Connector spec for modeling at least package parasitics. Bob mentioned that this had been discussed on the connector subcommittee. The applicability is not clear. Some members have issues with the connector spec. - Stephen Peters feels that this part of the specification is required in the first release. - Al may have time at some point to introduce his ideas on this. Al Davis is working on macro language presentation materials for the upcoming summit. Handouts will be printed for materials sent to Kathy Breda by Thursday, Sep 7. After that, 40-50 copies should be brought to the meeting. Although Arpad could not attend, here is a mail from him with his input for the meeting: I am sorry I won't be able to call in this time. I am in an all day class today and tomorrow. I would like to make a comment (again) on the elements list (file name: circuit). If we have flux = ... for the inductors, should we also have E-field = ... for the capacitors? Also, the equation for the resistor still has V = ... and I = ... included. As far as I remember we agreed that those are voltage and current source equations, not resistor equations. Also, I thought we areed last time that we would use the "full" syntax for equations as I suggested, but make verbal statements for limitations (such as for level 1 you can only use the element's own two nodes in the equations, etc...). Also, I do not believe that we should have different elements for reasons that depend on the content of an equation. For example the Resistor and VCR should not be two different elements just because one is R=f(t) and the other is R=f(V). Both of these are RESISTORS, its is just the expression that is different! A general syntax for expressions should allow all this in one element. Whether the simulator needs to deal with it differently or not, should not be burdening the user or model maker. We need a clean, and simple syntax. I wonder about the admittance element. What is its meaning? Should we also have its couterpart, impedance element? If so, what is its meaning? Are we getting into complex numbers here or what? So much for now, thanks, Arpad =========================================================== 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.