Minutes of 8/22/2000 IBIS-X teleconference Attending: Mike Cohen, Bob Ross, Mike LaBonte, Arpad Muranyi, Al Davis, John Angulo 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. - The argument to the .select statement is an environment attribute. There will be explicit declarations of environment attributes. AR: Al will write an example. We reviewed the models file. - A question arose on whether we should we have the ".local" statement. This formally declares the names of new nodes that are local to the circuit module. We decided to renamed it to ".node", to make clear what it is. It should be required, not optional. We reviewed Arpad's macro. One of the statements is: C TTgnd (IO_pad gnd_clamp_ref) C = TTgnd * [GND Clamp](V(IO_pad power_clamp_ref)) / VT || open - Should we allow V(arbitrary nodes) ? Hyperlynx and Cadence do not support this, maybe others do not. Allowing only "V" is easier to implement. Arpad suggests we adopt the more flexible format even if the node names that may be used are initially restricted to the element terminals. There was agreement to this. We discussed possible future extensions beyond the first release:. - Berkeley B element (ability to have arbitrary node voltages in expressions) - Code models. - AMS simulation language. Will golden parser code be available for the new IBIS? Al plans to implement it in ACS. It should be open source. Al would be willing to issue the source GPL, and charge for commercial versions. The IBIS committee would only have to certify it. We should discuss this at the upcoming summit meeting. It was suggested that the minutes should include an AR list. This can be done. How about listing issues, too? That may make the minutes quite long. We have a fragmented set of small documents comprising only a portion of what a final spec would be. Who will compile the linear, formal spec document? Stephen Peters will return, but will be unfamiliar with much of what has been discussed. Bob pointed out that at this point you have to be on the committee to know the concepts. 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.